Niko Mäkitalo REST POHJAINEN SISÄLLÖNHALLINTAJÄRJESTELMÄ HAJAUTETTUUN YMPÄRISTÖÖN. Diplomityö

Transkriptio

1 Niko Mäkitalo REST POHJAINEN SISÄLLÖNHALLINTAJÄRJESTELMÄ HAJAUTETTUUN YMPÄRISTÖÖN Diplomityö Tarkastajat: Tommi Mikkonen, Timo Aaltonen, Janne Lautamäki Tarkastaja ja aihe hyväksytty Tieto- ja sähkötekniikan tiedekuntaneuvoston kokouksessa

2 II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan koulutusohjelma MÄKITALO, NIKO: REST POHJAINEN SISÄLLÖNHALLINTAJÄRJESTELMÄ HAJAUTETTUUN YMPÄRISTÖÖN Diplomityö, 78 sivua, 2 liitesivua Tammikuu 2011 Pääaine: Ohjelmistotuotanto Tarkastajat: Prof. Tommi Mikkonen, TkT. Timo Aaltonen, DI. Janne Lautamäki Avainsanat: REST, hajautettu järjestelmä, sisällönhallinta Digitaalisen tietosisällön määrä maailmassa kasvaa kiihtyvällä tahdilla. Käyttäjille tarjotaan yhä uusia tapoja tuottaa sisältöä, ja heillä on käytössään yhä enemmän sisältöä varastoimaan kykeneviä teknisiä laitteita. Sisällön hallitseminen manuaalisesti on kestämätön ratkaisu, sillä sisällön hallitseminen on haastavaa, aikaavievää ja muodostaa nopeasti paisuvan ongelman. Lisäksi käyttäjien laitteiden muisti saattaa olla tehottomasti käytössä. Tässä diplomityössä tutkitaan, miten hajautetussa ja heterogeenisessä ympäristössä sijaitsevaa sisältöä voidaan hallita. Ongelman ratkaisemiseksi perehdytään sisällönhallintaan liittyviin keskeisimpiin käsitteisiin, sekä sisällönhallitajärjestelmältä vaadittaviin ominaisuuksiin. Hajautetun ja heterogeenisistä laitteista muodostuvan ympäristön vaikutuksia sisällönhallintaan on myös pyritty kartoittamaan. Lisäksi tutkitaan minkälaisia teknologioita tämänkaltaiseen ympäristöön suunnatun sisällönhallintajärjestelmän toeuttamisessa on mahdollista käyttää. Diplomityön teknsisenä kontribuutiona on toteutettu VisualREST niminen sisällönhallintajärjestelmä hajautettuun heterogeeniseen ympäristöön. Järjestelmän tarkoituksena on tarjota käyttäjille yhtenäinen tapa, jonka avulla he voivat hallinnoida kaikissa laitteissaan sijaitsevaa sisältöä samojen helppokäyttöisten ja tehokkaiden periaatteiden mukaan. Järjestelmä noudattaa pilvilaskennasta ja hajautetuista järjestelmästä peräisin olevaa ajattelumallia, jonka mukaan taustalla toimivat prosessit ja järjestelmän fyysinen rakenne on pyritty abstrahoimaan. Rajapinnan toteutuksessa käytetyt REST suunnitteluperiaatteet ovat osoittautuneet erittäin toimivaksi tavaksi suunnitella ja toteuttaa intuitiivinen ja yhtenäinen rajapinta hajautettuun sisällönhallintajärjestelmään. Tulosten arvioinnin perusteella toteutetun järjestelmän voidaan katsoa täyttävän sisällönhallintaan liittyvät ominaisuudet hyvin. Esille nousee kuitenkin joitain parannusehdotuksia sekä jatkokehitysajatuksia.

3 III ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master s Degree Programme in Information Technology MÄKITALO, NIKO: RESTful content management system for distributed environment Master of Science Thesis, 78 pages, 2 Appendix pages January 2011 Major: Software Engineering Examiners: Prof. Tommi Mikkonen, Dr. Tech. Timo Aaltonen, MSc. Janne Lautamäki Keywords: REST, distributed system, content management The amount of digital content is continuously increasing with accelerating speed. More and more new ways to produce digital content are becoming available. Users also have many devices that can store digital information. Handling this content manually is an unsustainable solution and soon leads to a swelling problem because of the challenging and time consuming nature of content management. Also the memory of users devices is often used in an inefficient way. This thesis studies how content can be managed in a heterogenous and distributed environment. To solve this problem some of the most crucial features and concepts of content management is first introduced. The impact that distributed and heterogeneous environment causes for the content management is surveyed. The thesis also studies what kind of technologies can be used for developing content management system in this kind of an environment. As a technical contribution of this thesis, a content management system named VisualREST has been implemented. The system is designed and implemented with the special characteristics of the distributed and heterogenous environment in mind. The main goal of this system is to provide a uniform way for users to manage the content stored in all of their devices with the same user friendly and efficient principles. As cloud computing and distributed systems in general, also VisualREST tries to abstract away the physical structure and complicated processes from user perspective. REST guidelines that were used for implementing the interface for the system turned out to be a good way to design and implement a uniform and intuitive interface for a distributed content management system. While evaluating the results of this thesis, VisualREST was discovered to fulfill the requirements of the content management quite well. However, some improvement proposals and future development ideas emerged.

4 IV ALKUSANAT VisualREST projekti käynnistyi alkukesästä 2009 Nokia Research Centerin ja Tampereen Teknillisen yliopiston tutkimusprojektina. Myöhemmin mukaan on tullut myös Aalto yliopisto sekä muita osapuolia. Työssä toteutettu järjestelmä on edelleen aktiivisen tutkimuksen ja kehityksen kohteena. Projektiin on osallistunut monia osapuolia, mutta erityisesti haluan kiittää Tommi Mikkosta, joka on antanut minulle mahdollisuuden työskennellä tässä projektissa, ja joka on kärsivällisesti jaksanut antaa tästä diplomistyöstä asiantuntevaa ja kannustavaa palautetta. Lisäksi haluan kiittää Timo Aaltosta, joka alunperin palkkasi minut projektia tekemään. Erityisesti haluan myös kiittää Jenniä ja vanhempiani tuesta ja ymmärryksestä. Tampereella, 17. joulukuuta Niko Mäkitalo

5 V SISÄLLYS 1. Johdanto Taustaa Hajautettu järjestelmä Pilvilaskenta Teknologiat pilvipalveluiden taustalla REST suunnitteluperiaatteet Sisällönhallinta Sisältö, metatieto ja essentia Sisällönhallintajärjestelmien ominaisuuksia Sisällön hakeminen ja hakutulosten esittäminen Metatietojen tuottaminen Sisällön saatavuus Sisällön versiointi Sisällön oikeuksien hallinta Järjestelmän yleiskuvaus Palvelinohjelmiston yleiskuvaus Tietosäiliöohjelman yleiskuvaus Vaatimukset tietosäiliöohjelmalle Esimerkkitoteutuksen yleiskuvaus REST sisällönhallinnan näkökulmasta Palvelinohjelmiston REST rajapinnan kuvaus Konteksti: käyttäjätunnus Konteksti: käyttäjätunnus ja ryhmätunnus Konteksti: käyttäjätunnus ja laitetunnus Konteksti: käyttäjätunnus, laitetunnus ja tiedosto Muut kontekstit ja resurssit HTTP paluukoodit URI osoitteiden kyselyosa Arkkitehtuuri ja toteutus VisualREST palvelimen arkkitehtuuri Toteutusteknologiana Ruby on Rails Fyysinen näkymä Palvelinohjelmiston tietosisältö ja mallit Palvelinohjelmiston rakenne Tietosäiliöohjelman esimerkkitoteutus Rakenne ja toimintaperiaatteet Tietosäiliöohjelman ylläpitämät tiedostot

6 VI 4.3 Versionhallintajärjestelmänä GIT Versioinnin toteuttaminen GIT:n avulla GIT:n Ruby sovellusrajapinta Allekirjoitusten laskeminen Tietosäiliöohjelman ja palvelimen yhteistoiminta Metatietojen päivittäminen palvelimelle Essentian välittäminen tietosäiliöohjelmalta asiakasohjelmalle Arviointi Sisällönhallinnan ominaisuuksien toteutuminen Sisällön hakuominaisuudet Sisällön kuvaileminen Sisällön saatavuuden turvaaminen Sisällön käyttäjäkohtaiset asetukset Teknologioiden soveltuvuus tarkoituksiinsa REST suunnitteluperiaatteiden noudattaminen Hajautetun järjestelmän ominaisuuksien toteutuminen Git versionhallintaan liittyvät ongelmat Ruby ja mobiili ympäristö Jatkokehitysajatukset Käyttöympäristöön perustuva konteksti Ilmoitukset Essentian välittäminen laiteelta laitteelle Yhteenveto A. Esimerkki metatietolista B. Hakutulosten Atom syöte

7 1 1. JOHDANTO Hajautettu heterogeeninen ympäristö koostuu useista toisistaan poikkeavista tietokoneista, jotka kommunikoivat keskenään tietoverkkojen välityksellä. Tietokoneet voivat tämänkaltaisessa ympäristössä olla esimerkiksi monesta suorittimesta koostuvia, raskaaseen laskentaan erikoistuneita palvelinkoneita, normaaliin käyttöön soveltuvia kannettavia tietokoneita, tai kevyeen laskentaan kykeneviä matkapuhelimia. Tietokoneen tärkein ominaisuus tästä näkökulmasta on sen kyky muodostaa verkkoyhteys muihin järjestelmään kuuluviin tietokoneisiin. Erilaisten digitaalista tietosisältöä tuottamaan kykenevien laitteiden määrä jatkaa kasvuaan kiihtyvällä tahdilla. Myös laitteiden kyky varastoida sisältöä on kasvanut huomattaviin mittasuhteisiin, ja tänäpäivänä esimerkiksi matkapuhelimet voivat tallettaa moninkertaisen määrän tietoa kymmenen vuoden takaisiin kotitietokoneisiin verrattuna. Usein käyttäjät ovat myös halukkaita jakamaan erilaisissa käyttötilanteissa tuottamaansa sisältöä esimerkiksi ystävien ja työtovereiden kesken. Käyttäjien kannalta olisikin hyödyllistä, mikäli he voisivat hallinnoida kaikkea sisältöä samoja intuitiivisia ja tehokkaita toimintatapoja noudattaen. Tässä diplomityössä tutkimusongelman muodostavat sisällönhallintaan liittyvät piirteet. Työssä pyritään tutkimaan sitä, miten hajautetussa ja heterogeenisessä ympäristössä sijaitsevaa sisältöä voidaan hallita? Tähän kysymykseen vastaamiseksi tulee kuitenkin ensin määritellä, mitä ratkaistavia ongelmia liittyy sisällönhallintaan, mitä ominaisuuksia sisällönhallintajärjestelmältä vaaditaan, sekä miten hajautettu heterogeeninen ympäristö vaikuttaa sisällönhallintaan? Lisäksi työssä pyritään vastaamaan siihen, mitä teknologioita tämänkaltaiseen ympäristöön suunnatun sisällönhallintajärjestelmän toteutuksessa voidaan käyttää? Diplomityössä on toteutettu VisualREST niminen sisällönhallintajärjestelmä. Järjestelmän tarkoituksena on tuoda sisältö lähemmäs käyttäjää, sillä käyttäjien tuottama sisältö on tyypillisesti sijoittunut hyvin hajanaisesti erilaisiin laitteisiin, mikä hankaloittaa sisällön etsintää ja ylläpitoa. Toteutetun järjestelmän avulla käyttäjille pyritään tarjoamaan yhtenäinen rajapinta, jonka avulla he voivat hallinnoida kaikissa laitteissaan sijaitsevaa sisältöä samojen helppokäyttöisten ja tehokkaiden periaatteiden mukaan. Suunnittelussa on pyritty ottamaan huomioon, sekä myös hyödyntämään hajautetun heterogeenisen ympäristön piirteitä. Järjestelmä jaotteleekin sisällön kahdeksi erilliseksi käsitteeksi: metatiedoiksi ja essentiaksi. Järjestelmän toi-

8 1. Johdanto 2 mintafilosofian mukaan sisältöä kuvailevat ja etsinnän apuna käytettävät metatiedot pyritään pitämään aina saatavissa keskitetyllä palvelimella, ja sisällön varsinainen essentia mahdollisuuksien mukaan sen tuottaneen laitteen hallussa. VisualREST järjestelmään on haluttu tarjota yhtenäinen rajapinta, joka abstrahoi järjestelmän fyysisessä rakenteessa ilmenevät eroavaisuudet. Näin on toimittu siksi, ettei järjestelmän fyysisellä rakenteella sinällään ole merkitystä sisällönhallinnan näkökulmasta. Yksinkertaistaen voidaan todeta, että sisällönhallinnan näkökulmasta tietokone ja sen sisältö joko on tai ei ole saatavissa. Tässä työssä tullaan kuitenkin huomaamaan, että todellisuudessa tietokoneen saatavuuteen vaikuttaa myös sen käyttöympäristö, laitetyyppi, käytössä olevat verkkoyhteydet, tietoturvaratkaisut ja monet muut asiat. Järjestelmän yhtenäinen rajapinta on toteutettu noudattaen REST suunnitteluperiaatteita, ja tarjoaa näin ollen intuitiivisen ja tehokkaan tavan järjestelmän resurssien käsittelemiseen. Suunnitteluperiaatteet pyrkivät standardien mukaisella tavalla hyödyntämään hyvin yleisesti käytössä olevan HTTP protokollan ominaisuuksia ja URI osoitteita. Rajapinnan toteutustapa tarjoaa hyvät lähtökohdat järjestelmää käyttävien asiakasohjelmien toteuttamiselle. VisualREST järjestelmän pääasiallinen käyttötarkoitus onkin toimia tietyllä tapaa välikerroksena sitä tämän yhtenäisen rajapinnan kautta käyttäville asiakasohjelmille. Pyrkimys järjestelmän fyysisen rakenteen abstrahoimiseen soveltuu myös pilvilaskennan ajatusmalliin. Pilvilaskennassa prosessin abstrahointi on pyritty viemään hyvin pitkälle, sillä tyypillisesti käyttäjille tarjotaan yksinkertainen rajapinta, joka ottaa vastaan syötteen, ja palauttaa sen perusteella jonkin ulostulon paljastamatta käyttäjälle taustalla olevaa monimutkaista prosessia. Samaan tapaan VisualREST järjestelmän voidaan katsoa pyrkivän abstrahoimaan taustalla olevat prosessit, tarjoten käyttäjille yksinkertaisen rajapinnan käyttäjien laitteiden ja niiden sisältöjen muodostamaan pilveen. Luvussa 2 on määritelty sisällönhallintaan ja sisällönhallintajärjestelmään liittyvää taustatietoa. Pyrkimyksenä on määrittellä yksikäsitteisesti sisällönhalintaan liittyvät käsitteet ja termistö, sekä keskeisimmät sisällönhallinnan ominaisuudet. Lisäksi perehdytään hajautetun järjestelmän käsitteeseen, pilvilaskentaan ja sen taustalla oleviin teknologioihin, sekä järjestelmän yhtenäisen rajapinnan suunnittelussa käytettyihin REST suunnitteluperiaatteisiin. Luvussa 3 luodaan yleiskatsaus VisualREST järjestelmään, kuvaten sen toimintaa korkealla tasolla. Tässä luvussa tutustutaan myös järjestelmän asettamiin vaatimuksiin metatietoja tuottavalle ja sisällön essentiaan varastoivalle tietosäiliöohjelmalle, ja niiden pohjalta toteutettuun esimerkkitoteutukseen. Lisäksi kuvaillaan REST suunnitteluperiaatteiden pohjalta toteutettu järjestelmän yhtenäinen rajapinta. Luvussa 4 perehdytään järjestelmän yksityiskohtaisempaan toteutukseen, ja tarkastellaan arkkitehtuuria eri näkökulmis-

9 1. Johdanto 3 ta. Lisäksi kuvataan esimerkkinä toteutetun tietosäiliöohjelman ja palvelimen välistä yhteistoimintaa keskeisimpien toimintojen osalta. Luvussa 5 arvioidaan miten hyvin työssä toteutettu järjestelmä täyttää sisällönhallintaan liittyvät ominaisuudet, teknologioiden soveltumista käyttötarkoituksiinsa, sekä kuvaillaan muutamia jatkokehitysajatuksia. Kaikkien näiden yhteydessä pyritään tuomaan esille niiden käytössä ilmenneitä ongelmia ja ristiriitaisuuksia, sekä antamaan ratkaisu- ja parannusehdotuksia.

10 4 2. TAUSTAA Digitaalisen tietosisällön hallinta on moniulotteinen ongelma, johon ei ainakaan toistaiseksi ole löytynyt yleistä ratkaisua. Sisällönhallinnan näkemistä moniulotteisena ongelmana tukee se, että sisällönhallinnan tarpeisiin on kehitetty lukuisia toisistaan poikkeavia ratkaisuja, mutta yleisiä suuntalinjoja on syntynyt vain muutamia. Erilaiset sisällönhallinnan ratkaisut on kehitetty ratkaisemaan niiden ongelmien joukko, jotka on synnyttänyt tarve hallita sisältöä. Näiden sisällönhallintaan liittyvien ongelmien voidaan kuitenkin nähdä toistuvan hyvin samankaltaisina kaikissa sisällönhallintaan kehitetyissä työkaluissa. Eroavaisuudet näiden ongelmien välillä ja erityisesti niiden ratkaisujen toteutuksissa saattavat johtua näkökulmaeroista. Näkökulma vaihtelee ainakin sen mukaan minkälaista tietosisältöä ollaan hallitsemassa ja mitkä ovat tämän sisällön käyttötarpeet. Tässä luvussa pyritään nostamaan esille erilaisten sisällönhallintajärjestelmien kuvauksissa esitettyjä ongelmia, näkökulmia ja ominaisuuksia. Lisäksi märitellään sisällönhallintaan ja sisältöön liittyviä keskeisimpiä käsitteitä, jotta ne voitaisiin jatkossa ymmärtää yksikäsitteisesti. Näiden esilletuotujen seikkojen ja määriteltyjen käsitteiden avulla pyritään määrittelemään se, mitä sisällönhallinnalla ja sisällönhallintajärjestelmällä tarkoitetaan yleisesti, ja minkälaisiin ongelmiin sisällönhallintajärjestelmän voidaan olettaa tarjoavan ratkaisuja. Ennen sisällönhallintaan tutustumista perehdytään kuitenkin hajautetun järjestelmään, pilvilaskentaan, sekä muihin teknologioihin jotka toimivat tässä työssä kuvattavan sisällönhallintajärjestelmän taustalla. 2.1 Hajautettu järjestelmä Tanenbaum ja Steen antavat hajautetulle järjestelmälle seuraavan yleisen määritelmän: hajautettu järjestelmä on joukko itsenäisiä tietokoneita, jotka näyttäytyvät käyttäjälle yhtenä yhtenäisenä ja johdonmukaisena järjestelmänä [33, s. 2]. Kyseiseen määritelmään sisältyy sekä laitteistoon että ohjelmistoon liittyvä näkökulma. Laitteiston näkökulmasta hajautettu järjestelmä koostuu riippumattomista tietokoneista, joiden fyysinen rakenne ja sijoittelu saattaa vaihdella, eikä määritelmä näin ollen rajoita järjestelmän rakennetta tai arkkitehtuuria. Hajautetun järjestelmän tietokoneet voivat esimerkiksi jakaa yhteisen muistin, tai jokaisella tietokoneella voi olla käytössään fyysisesti oma muistinsa. Lisäksi järjestelmän tietokoneet voivat

11 2. Taustaa 5 olla esimerkiksi monesta suorittimesta koostuvia, raskaaseen laskentaan erikoistuneita palvelinkoneita, normaaliin käyttöön soveltuvia kannettavia tietokoneita, tai kevyeen laskentaan soveltuvia matkapuhelimia. Tämänkaltaista useista erilaisista tietokoneista koostuvaa järjestelmää kuvaillaan termillä heterogeeninen ympäristö. Useista samanlaisista tietokoneista koostuvaa ympäristöä puolestaan kuvaillaan termillä homogeeninen ympäristö. Yhteisen muistin jakavat tietokoneet kommunikoivat tyypillisesti muistin välityksellä. Tietokoneet, joilta yhteinen muisti puuttuu, kommunikoivat keskenään hyödyntäen erilaisia verkkoja. Usean erilaisen kommunikointikanavan hyödyntäminen osaltaan mahdollistaa entisestään heterogeenisemman laiteympäristön muodostumisen. Hajautettu järjestelmä saattaa näin ollen koostua esimerkiksi useista erilaisista toisiinsa kytketyistä lähiverkoista. [33, s. 17] Yllä esitetyn määritelmän ohjelmistoon liittyvän näkökulman mukaan hajautettu järjestelmä voidaan nähdä ohjelmistona, joka osaltaan kätkee käyttäjiltä järjestelmän fyysisen rakenteen. Tätä kykyä kätkeä järjestelmän monimutkainen ja heterogeeninen luonne voidaankin pitää yhtenä hajautetun järjestelmän merkittävimmistä ominaisuuksista, ja siitä käytetään termiä tuntumattomuus (engl. transparency). Toinen tärkeä seikka hajautetun järjestelmän ohjelmistoon liittyen on sen kyky toimia eräänlaisena resursseja automatisoidusti kontrolloivana työkaluna, jonka avulla lukuisat käyttäjät ja sovellusohjelmat voivat kaikki käyttää samoja järjestelmän ylläpitämiä resursseja. Näin ollen käyttäjiltä myös piilotetaan tieto siitä, mitkä järjestelmän resurssit ovat tietyllä ajan hetkellä saatavissa. Äärimmäisyyksiin viety tuntumattomuus ei kuitenkaan aina ole järkevää järjestelmän käytön kannalta, kuten tässä työssä myöhemmin tullaan huomaamaan. Tanenbaun ja Steen korostavat juuri ohjelmiston merkitystä hajautetussa järjestelmässä. Heidän mukaansa laitteistokin on merkityksellinen, mutta juuri ohjelmisto määrittelee hyvin suuressa määrin sen, miten järjestelmä ulospäin näyttäytyy käyttäjille [33, s. 22]. Tarjotakseen heterogeeniseen ja useista laitteista koostuvaan järjestelmään vain yhden yhtenäisen näkymän, hajautetut järjestelmät pohjautuvat usein kerrosarkkitehtuuriin. Tämänkaltaisessa arkkitehtuurissa hajautetun järjestelmän ohjelmisto toimii eräänlaisena välikerroksena (engl. middleware), joka sijoittuu käyttöjärjestelmien ja hajautettua järjestelmää käyttävien sovellusohjelmien väliin. Välikerros käyttää hyväkseen niitä palveluita, jotka heterogeenisten käyttöjärjestelmien joukko tai vastaavasti muut järjestelmät tarjoavat. Kuvassa 2.1 on esitetty, miten hajautettu järjestelmä tarjoaa yhtenäisen välikerroksen sitä käyttäville sovelluksille. Kuvan järjestelmä koostuu kolmesta erillisestä tietokoneesta, jotka kommunikoivat keskenään käyttäen verkkoa. Välikerroksen etuina voidaan myös nähdä sen kyky parantaa järjestelmän skaalautuvuutta (engl. scalability) ja avoimuutta (engl. openness). Skaalautuvuudella

12 2. Taustaa 6 Kuva 2.1: Hajautetun järjestelmän kerrosrakenne [33]. tarkoitetaan järjestelmän suorituskyvyn muutosta kun järjestelmää laajennetaan. Hyvin toteutettu välikerros osaakin hyödyntää järjestelmään tuotuja uusia resursseja samoin kuin vanhojakin resursseja. Avoimuus kuvaa sitä, miten järjestelmää voidaan laajentaa ja sen osia korvata uusilla toteutuksilla. Järjestelmän avoimuutta parantaa välikerroksen tarjoama yhtenäinen rajapinta, joka järjestelmän osien tulee toteuttaa. Avoimuutta voidaan mitata muun muassa järjestelmän osien välisellä yhteensopivuudella (engl. interoperability) sekä, miten helposti järjestelmän osat ovat siirrettävissä ympäristöjen välillä (engl. portability). [33, s. 4 15] 2.2 Pilvilaskenta Pilvilaskentaa (engl. cloud computing) voidaan pitää tietyllä tapaa hajautetun järjestelmän erikoistapuksena, sillä pilvipalvelujärjestelmien laitteisto- ja ohjelmistoalustoina toimivat tyypillisesti erilaiset hajautetut järjestelmät. Toisaalta sekä pilvilaskenta että hajautetut järjestelmät pyrkivät samankaltaisiin tavoitteisiin. Hajautetun järjestelmän tapaan pilvilaskentaa suorittava palvelu pyrkii piilottamaan taustalla toimivan järjestelmän, ja tarjoamaan käyttäjille helppokäyttöisen ja yhtenäisen rajapinnan. Rajapinta ottaa vastaan syötteen, ja palauttaa sen perusteella jonkin ulostulon, ilman että käyttäjien tarvitsee välittää siihen liittyvästä prosessista. Tämänkaltaisen abstrahoinnin johdosta pilvilaskentaa onkin verrattu olio ohjelmointiin, ja siitä puhutaan toisinaan tämän eräänlaisena jatkeena. Absrahoimalla pois monimutkaiseen prosessiin liittyvät yksityiskohdat, järjestelmistä saadaan käyttäjäystävällisiä, menettämättä kuitenkaan monimutkaisen prosessin tarjoamia etuja. [11, s. 4]

13 2. Taustaa 7 Hajautettujen järjestelmien tapaan myös pilvilaskentaan suunnatut järjestelmät pyrkivät skaalautumaan tarpeen niin vaatiessa. Skaalautuvuutta pyritään tarjoaamaan asiakkaille muun muassa suurien palvelinkeskuksien avulla. Niissä voidaan järjestelmän toiminnan tehostamiseksi käynnistää uusia instansseja suuren kuormituksen alla olevista järjestelmän osista. Lisäksi pilvipalvelut mielletään turvallisiksi tiedon säilytyspaikoiksi, joiden varastoima tieto on aina varmuuskopioitua. Pilvilaskennalle ei toistaiseksi ole mitään selkeää ja yksikäsitteistä määritelmää. Erdogmus kokoaa artikkelissaan [11] yhteen joukon pilvilaskennan määritelmiä. Näille määritelmille yhteistä on palveluiden ja ohjelmistojen siirtyminen pilveen, josta käyttäjien on mahdollista päästä niihin verkon välityksellä käsiksi käyttäen helppokäyttöistä rajapintaa mistä ja milloin tahansa. Tyypillisesti pilven käsite mielletään näissä määritelmissä tarkoittamaan internettiä, tai suuria palvelinkeskuksia. Esimerkiksi Amazon Web Services tarjoaa joukon pilvialustoja, joita voidaan käyttää muun muassa pilvilaskentaan, sekä tiedon varastoimiseen ja välittämiseen. Palveluiden hinta määräytyy pääasiassa käytön mukaan, eikä palveluihin tarvitse sitoutua määräaikaisin sopimuksin. Toisaalta pilvipalveluita käyttämällä voidaan säästää laitteiston ja ohjelmistojen hankintakustannuksissa, kun yritysten ei tarvitse ostaa kalliita palvelimia tai ohjelmistolisenssejä. Lisäksi palveluita lakkautettaessa kalliit laitteistot eivät jää yritysten huoliksi. Kustannusten syntymistä käytön perusteella voidaankin pitää yhtenä pilvilaskennan merkittävimmistä eduista, ja osaltaan myös syynä pilvilaskennan kasvavaan suosioon [5]. Amazon Elastic Compute Cloud (Amazon EC2 ) on elastinen pilvialusta, joka mahdollistaa helposti skaalattavan tavan luoda pilvilaskentaympäristöjä. Palvelun avulla voidaan luoda virtuaalinen palvelin ja valita siihen käyttöjärjestelmä lukuisien eri vaihtoehtojen joukosta. Amazon Simple Storage Service (Amazon S3 ) on helppokäyttöisen REST käyttöliittymän kautta toimiva palvelu tiedon varastoimiseen. Tätä samaista palvelua käytetään hyväksi myös Amazonin omissa järjestelmissä. Helppokäyttöisyyden ja kustannustehokkaan hinnoittelun vuoksi Amazon Web Services palvelut ovat nousseet suureen suosioon. [3] 2.3 Teknologiat pilvipalveluiden taustalla Pilvipalveluiden ymmärretään usein rakentuvan web teknologioiden ympärille [11, s. 4]. Pilvilaskentaa suorittavan järjestelmän toteuttaminen ei kuitenkaan edellytä minkään tietyn yksittäisen web teknologian käyttämistä, vaan teknologioiden erittäin runsasta joukkoa on mahdollista soveltaa hyvinkin monipuolisesti. Koska teknologioita pilvipalveluiden toteuttamiseksi on erittäin runsas joukko, ja niiden läpi käyminen tässä ei olisi tarkoituksenmukaista, perehdytään seuraavaksi tässä työssä kuvattavan pilvipalvelun taustalla oleviin teknologioihin. Kuvassa 2.2 on esitetty, miten teknologiat muodostavat kerrosmaisen rakenteen.

14 2. Taustaa 8 Kuten jo mainittiin pohjautuvat pilvipalvelut web teknologioihin. WWW, joka on lyhennelmä sanoista World Wide Web, ja josta käytetään termiä web, toimii maailman laajuisessa Internet verkossa. Web teknologiat pohjautuvat resurssien välittämiseen HTTP protokollan (Hypertext transfer protocol) välityksellä [13]. Muodoltaan nämä resurssit voivat olla esimerkiksi HTML dokumentteja (hypertext markup language) tai XML dokumentteja (extensible markup language). Resurssin muoto ei kuitenkaan ole sidottu, vaan protokollan välityksellä voidaan välittää mitä tahansa tekstimuotoista sisältöä, tai esimerkiksi binäärimuotoista dataa. HTTP protokollan käyttäminen perustuu asiakas palvelin malliin, jossa asiakas lähettää HTTP pyyntöjä (HTTP request), ja joihin palvelin vastaa HTTP vastauksin (HTTP response). Sekä pyyntö että vastaus voivat sisältää otsakkeita (engl. header), ja runko osan (engl. body). HTTP pyyntö sisältää lisäksi käytettävän HTTP protokollan metodin, sekä polun (engl. path) joka on peräisin resurssien yksilöllisistä URI osoitteista (uniform resource identifier). Osoitteeseen voi lisäksi liittyä kyselyosa, joka sisältää pyynnölle annettavia parametreja, tai vastaavasti parametrit voidaan antaa pyynnön runko osassa. HTTP vastaus sisältää lisäksi paluukoodin, joka viestii operaation onnistumisesta. Paluukoodin käyttäminen on asiakasohjelmille tehokas keino päätellä operaation onnistumisesta, sillä vastauksesta tarvitsee lukea vain kolme ensimmäistä tavua [27, s. 376]. Näihin HTTP protokollan ominaisuuksiin, ja niiden tarkoituksenmukaiseen hyödyntämiseen perehdytään REST suunnitteluperiaatteiden kuvauksen yhteydessä. Kuva 2.2: Protokollien kerrosrakenne. HTTP protokolla käyttää hyödykseen alemman kerroksen TCP/IP protokollien (Transmission Control Protocol / Internet Protocol) yhdistelmää [20]. Tämä protokollien yhdistelmä huolehtii ip pakettien välittämisestä, ja internettiin kytkettyjen laitteiden osoitteistamisesta. Protokollaa hyödyntävät lukuisat muutkin ylemmän

15 2. Taustaa 9 tason protokollat, kuten esimerkiksi seuraavaksi kuvailtava XMPP protokolla. XMPP protokolla (extensible messaging and presence protocol) [21] tarjoaa tavan viestien välittämiseen ja läsnäolon seurantaan. Se käyttää viestien välittämiseen XML muotoa, ja tarjoaa näin ollen tavan lähettää pieniä XML dokumentteja tai niiden osia asiakkaiden välillä. Varsinainen viestin sisältö voi kuitenkin olla muodoltaan minkälaista tekstiä hyvänsä. XMPP on avoin teknologia, jolla tarkoitetaan ettei sen kehittäminen perustu mihinkään tiettyyn projektiin. Sen sijaan XMPP määrittelee joukon avoimia protokollia, jotka voidaan toteuttaa kenen toimesta hyvänsä. Saint-Andre et al. kirjoittavat että vaikka perinteisesti pilvilaskennassa ja välikerrosten toteuttamisessa on käytetty raskaampia protokollia kommunikoinnin toteuttamiseen, XMPP on kuitenkin yleistynyt myös tämänkaltaisten palveluiden toteuttamisessa. Lisäksi XMPP on jatkuvan tutkimuksen alaisena tämänkaltaisten palveluiden toteutusteknologiana. [30, s. 6] Aikaisemmin mainittiin, että HTTP protokollan välityksellä voidaan välittää XML muotoisia resursseja. XML on monipuolisuutensa ja laajennettavuutensa ansiosta käyttökelpoinen formaatti joissain tilanteissa, mutta oman räätälöidyn XML dokumenttityypin määrittäminen resurssien representaatioiden esittämiseen ei kuitenkaan aina ole ideaalein vaihtoehto. Tyypillisesti itse määriteltyjen XML dokumenttien käyttäminen vaatii myös räätälöityjen asiakasohjelmien toteuttamista. Tästä johtuen usein onkin perusteltua käyttää jo valmiiksi määriteltyä ja standardia formaattia tietojen esittämiseen. Atom syöte [25] on laajasti tuettu formaatti, joka mahdollistaa useiden valmiiden asiakasohjelmien käyttämisen. [35, s. 182] 2.4 REST suunnitteluperiaatteet REST suunnitteluperiaatteet on alunperin esitellyt Fielding tohtorin väitöskirjassaan [14], ja ne ovat myöhemmin saaneet suuren suosion. Tähän asti REST suunnitteluperiaatteista on kuvailtu vain yksittäisiä ominaisuuksia järjestelmän toimintaperiaatteiden ymmärtämisen tueksi. Seuraavaksi tutustutaan yksityiskohtaisemmin REST:in määrittelemiin suunnittelukriteereihin, sekä siihen mitä nämä kriteerit tarkoittavat käytännössä. Richardson ja Ruby [27, s. 80] totetavat, että vaikka REST kokoaa yhteen joukon suunnitteluperiaatteita, ei tästä huolimatta voida puhua REST arkkitehtuurista. Sen sijaan voidaan sanoa jonkin arkkitehtuurin täyttävän REST:in asettamat suunnitteluperiaatteet paremmin kuin jokin toinen arkkitehtuuri ne täyttää. REST ei näin ollen määrittele tiettyä yksittäistä arkkitehtuuria, vaan asettaa eräänlaiset suuntaviivat siitä, miten tiettyjen asioiden tulee järjestelmässä toteutua. [27, s. 80] REST suunnitteluperiaatteita noudattavaa järjestelmää voidaan kuvailla termillä RESTful. Kuten myöhemmin tullaan huomaamaan, ei näiden REST suunnitteluperiaatteiden noudattaminen aina käytännössä onnistu. Osaltaan tämä johtuu näi-

16 2. Taustaa 10 den suunnitteluperiaatteiden väljästä luonteesta, joka jättää varaa myös tulkinnalle. Toisaalta näitä suunnitteluperiaatteita vastaan on helppoa rikkoa myös käytännön tasolla, mutkia oikoen. Termi REST tulee englannin kielisistä sanoista representational state transfer. Nimen syvempi merkitys selkiintyy, kun ensin tutustutaan REST:in suunnitteluperiaatteisiin. Ennen näiden suunnitteluperiaatteiden tarkempaa kuvausta, avataan kuitenkin hieman REST:iin vahvasti liittyvää resurssin käsitettä, jonka tunteminen selkiyttää asiioiden kuvailemista. Richarson ja Ruby ilmaisevat resurssin käsitteen näin: "Resurssi voi olla mikä tahansa seikka, joka on tarpeeksi tärkeä, että siihen itseensä tulee voida viitata" [27, s. 81]. Resurssi voi näin ollen käytännössä siis olla mikä tahansa asia, johon on mahdollista viitata, sillä asioiden tärkeys on aina suhteellinen käsite. Tyypillisesti kuitenkin puhuttaessa verkkopalveluista ja ohjelmistoteknisistä asioista, voisi resurssi olla esimerkiksi tiedosto, järjestelmän luokka tai tietomalli, mutta toisaalta resurssi voi olla myös keinotekoisesti muodostettu asia, kuten käyttäjäryhmän käyttöoikeus tiettyyn tiedostoresurssiin. Resursseilla voi olla myös aliresursseja, jotka tämän tässä työssä kuvattavan järjestelmän kannalta ovat hyvinkin keskeisessä asemassa. Resurssit ja niiden aliresurssit muodostavat hierarkkisia kokonaisuuksia, ja juuri näiden resurssikokonaisuuksien hallintaan REST tarjoaa omat ratkaisunsa. Ensimmäinen REST:in asettama vaatimus on, että jokaisella järjestelmän resursilla tulee olla yksilöllinen osoite, kuten resurssin kuvauksen yhteydessä tuotiin jo esille (engl. addressability). Yleensä tämä osoite on URI osoite, vaikka REST ei itsessään vaadi minkään tietyn osoitetyypin käyttämistä. Richardson ja Ruby esittävät lisäksi, että URI osoitteen tulisi olla kuvaileva ja vastata intuitiivisesti resurssin sisältöä [27, s. 83]. Tyypillisesti REST rajapinnan URI osoitteista voidaan nähdä myös jo aikaisemmin mainittu hierarkkisuus resurssien ja niiden aliresurssien välillä. Osoitteiden loogisen rakenteen ansiosta REST rajapintaa käyttävien asiakasohjelmien on mahdollista luoda uusia resursseja järjestelmään, sekä viitata järjestelmän sisältöön. Yksilöllisten osoitteiden avulla saavutetaan myös eräs kiistämättömän tärkeä asia: on aina täysin selvää missä tietty yksittäinen resurssi sijaitsee. Tämän tiedon avulla resurssiin on aina mahdollista viitata, resurssin sisältö voidaan noutaa ja resurssia voidaan muokata. Tämän yksilöllisen osoitteen avulla resurssiin voidaan lisäksi viitata kaikkien käyttäjien ja kaikkien asiakasohjelmien keskuudessa, ja silti jokainen resurssiin viittaava voi olla täysin varma siitä, että kyseessä on sama resurssi. Tilattomuuden (engl. statelessness) suunnittelukriteeri liittyy vahvasti REST termin alkuperään: representational state transfer. Kuten lyhentämättömästä nimestä voidaan päätellä, on kyse resurssin tilan siirtämisestä ja esittämisestä. Tähän tarkoitukseen käytetään tyypillisesti HTTP protokollan pyyntöjä (HTTP request)

17 2. Taustaa 11 ja vastauksia (HTTP response). REST vaatii, ettei asiakasohjelman tila ole talletettuna palvelimelle, vaan asiakasohjelman tila tulee välittää HTTP pyynnön mukana. Pyyntöjen mukana tulee näin ollen välittää aina kaikki tarpeellinen tieto, jonka palvelin tarvitsee pyynnön suorittamiseen. Mikäli jotain tietoa tarvitaan toistuvasti, tulee tämä tieto välittää jokaisen pyynnön mukana. [27, s ] Kolmannen REST suunnittelukriteerin mukaan resurssien tulee olla yhteydessä toisiinsa (connectedness). Tämä suunnitteluperiaate toteutuu yleensä resurssien välisten linkkien avulla: resurssien representaatiot sisältävät URI osoitteita toisiin resursseihin. Tämänkaltainen toiminnallisuus on havaittavissa kaikissa hypermediajärjestelmissä, sillä juuri tämä representaatioiden linkittäminen toisiinsa luo pohjan koko webin toiminnalle. [27, s ] Representaatioiden sisältämät linkit saattavat viitata esimerkiksi resurssien omiin aliresursseihin. REST suunnitteluperiaatteita noudattava järjestelmä saattaa myös tarjota representaatioissa linkkejä, jotka ehdottavat asiakasohjelmalle seuraavaa mahdollista toimenpidettä. Tämänkaltainen ratkaisu saattaa tarjota eräänlaisen tavan kiertää REST suunnitteluperiaatteiden vaatimaa tilattomuuden vaatimusta, sillä REST ei kiellä tilan tallettamista osoitteeseen. Toisaalta taas palvelimen tiloja voidaan pitää resursseina, jolloin niillä tulee olla yksilöllinen osoite. Edellä esitellyt suunnitteluperiaatteet tukevat osaltaan REST:in neljättä suunnitteluperiaatetta, jonka mukaan kaikille resursseille tulee tarjota yhtenäinen rajapinta. Ensimmäisen suunnittelukriteerin mukaan jokaisella resurssilla tuli olla yksilöllinen osoite, jonka tulisi olla lisäksi rakenteeltaan looginen ja yhdenmukainen muiden samaa tyyppiä olevien resurssien kanssa. Toisen suunnitteluperiaatteen mukaan asiaksohjelman tila voitiin tarvittaessa välittää HTTP pyynnön mukana, mahdollisesti osoitteeseen talletettuna. Tämä vaatimus on luonnollisesti voimassa kaikille resursseille, ja osoitetta tiloineen tulee kaikkien asiakasohjelmien voida käyttää tilanteesta riippumatta. Kolmas suunnittelukriteeri vaati yhteyttä resurssien välille, joka käytännössä voidaan toteutetaan URI osoitteiden avulla resurssien representaatioissa. Myös tätä tapaa tulee noudattaa yhtenäisen linjan mukaisesti kaikille samaa tyyppiä oleville resursseille. Näiden kolmen ensimmäisen suunnittelukriteerin ansiosta resursseihin viittaaminen tapahtuu aina yhtenäisellä tavalla, asiakasohjelmasta tai tilanteesta riippumatta. Jotta voitaisiin puhua rajapinnasta, ei pelkkä yhtenäinen viittauskäytäntö resursseihin riitä, vaan resursseja tulee myös voida käsitellä. Käytettäessä HTTP protokollaa REST rajapinnan toteuttamiseen, voidaan hyödyntää protokollan omia metodeja siten, kuin niitä on HTTP standardin mukaan tarkoitettu käytettävän. Seuraavaksi kuvaillaan miten järjestelmän tulee toimia käytettäessä neljää yleisintä HTTP protokollan metodia: GET, PUT, POST ja DELETE. Tyypillisesti resurssien käsittelemiseen riittävät hyvin niin kutsutut CRUD ope-

18 2. Taustaa 12 raatiot. Kyseinen termi tulee englannin kielen sanoista: create (suom. luoda), read (suom. lukea), update (suom. päivittää) ja delete (suom. poistaa). HTTP protokollan edellä mainitut metodit tarjoavat luonnolliselta tuntuvan tavan kaikkien CRUD operaatioiden toteuttamiseksi. REST rajapinnan asiakas yksinkertaisesti suorittaa HTTP pyynnön haluamansa resurssin yksilölliseen URI osoitteeseen, ja valitsee haluamansa metodin. Pyynnön vastaanottaessaan palvelinohjelmisto päättelee asiakasohjelman käyttämästä metodista sen, miten osoitteen viittaamaa resurssia tullaan käsittelemään. Asiakasohjelman käyttäessä GET metodia, osoitteen viittaman resurssin representaatio noudetaan palvelimelta ja palautetaan asiakkaalle HTTP vastauksessa. Käytettäessä DELETE metodia osoitteen viittaama resurssi poistetaan palvelimelta. Luonnollisesti resurssien poistaminen vaatii usein käyttöoikeuksien tarkastelua. Toisinaan myös resurssin representaation noutaminen saattaa vaatia käyttöoikeuksien tarkastelua, mikäli resurssin sisältö tai olemassaolo halutaan rajata vain tietyn käyttäjäryhmän keskuuteen. Tässä kohdassa ei keskitytä REST rajapinnan käyttöoikeuksien valvontaan, mutta mainittakoon kuitenkin, että asiakasohjelman tunnistautumiseen käytettävät tiedot tulee aina välittää HTTP pyyntöjen mukana REST suunnitteluperiaatteiden tilattomuuden vaatimuksesta johtuen. [27, s. 97] Uusien resurssien luominen tapahtuu tekemällä HTTP pyyntö PUT metodia käyttäen luotavan resurssin URI osoitteeseen. Luotaessa uutta resurssia palvelimelle, on asiakasohjelman tehtävänä välittää luotavan resurssin representaatio palvelinohjelmalle. Ymmärrettävistä syistä johtuen, usein myös vaaditaan että asiakasohjelma välittää autentikointitiedot HTTP pyynön mukana. Uusien resurssien luomiseen voidaan käyttää vaihtoehtoisesti myös HTTP protokollan POST metodia. Richardson ja Rubyn mukaan PUT metodia tulee käyttää uusien resurssien luomiseen silloin, kun asiakasohjelma päättää tai voi olla varma siitä, mikä luotavalle resurssille tulee osoitteeksi. POST metodia käytetään vastaavasti silloin kun palvelinohjelmisto päättää luotavan resurssin osoitteen. Tämän toimintaperiaatteen ansiosta resursseille voidaan esimerkiksi luoda aliresursseja ilman, että asiakasohjelman tarvitsee välttämättä tietää luotavan resurssin absoluuttista polkua. Operaatio voidaan tässä tapauksessa tehdä resurssin osoitteeseen, jolloin palvelinohjelmisto voi päätellä, että ollaan luomassa aliresurssia. [27, s. 99] Kumpaakin metodia voidaan käyttää myös resurssin tilan päivittämiseen, mutta myös tässä tapauksessa metodeilla on hieman toisistaan poikkeava merkitys. PUT metodia käytettäessä URI osoitteen viittaaman resurssin tiedot korvataan parametrina annetuilla tiedoilla. Tietojen päivittäminen vaatii näin ollen aina olemassaolevan resurssin täydellisen polun. POST metodia käytettäessä parametrina annettua tietoa puolestaan lisätään osoitteen määräämälle resurssille. Tämä lisääminen voi tapahtua puhtaasti lisäämällä tietoja osoitteen viittaamalle resurssille itselleen, tai

19 2. Taustaa 13 kuten aikaisemmin mainittiin, uuden aliresurssin luomista osoitteen viittaamalle resurssille. [27, s ] Toisinaan REST rajapintaa toteutettaessa eteen tulee tilanteita, joissa on lähes mahdotonta välttyä tyypillisen RPC toiminnallisuuden 1 lisäämiseltä rajapintaan. Tyypillisesti tämänkaltaiset tilanteet liittyvät useiden resurssien välisiin suhteisiin ja yhtäaikaiseen käsittelyyn, kuten esimerkiksi jo olemassaolevan resurssin lisäämiseen toisen jo olemassaolevan resurssin aliresurssiksi. Useissa tapauksissa tämänkaltainen toiminnallisuus voidaan kuitenkin mieltää resurssin tietojen päivittämiseksi, vaikka operaatio ei vain yhtä tiettyä resurssia koskisikaan. Tämänkaltaisissa tilanteissa voidaan hyödyntää POST metodin kuormittamisen mahdollisuutta, jonka avulla resurssin tietojen muokkaaminen voidaan muuntaa eräänlaiseksi tietojenkäsittelyprosessiksi. Vaarana kuitenkin on, että REST rajapinnan yhtenäinen rakenne alkaa rikkoontua ja HTTP metodien käyttötarkoitus hämärtyä. Enää metodi ei suoraan kerro miten pyyntöön reagoidaan. [27, s. 101] Usein tämä tieto pyritään kuitenkin tuomaan rajapinnan käyttäjille näkyväksi, jolloin tiedon sijoittaminen URI osoitteeseen saattaa tuntua loogiselta vaihtoehdolta. Operaation nimen sijoittaminen URI osoitteeseen on kuitenkin erittäin tehokas tapa rikkoa REST suunnitteluperiaatteita vastaan. Tästä syystä POST metodin kuormittamisen suhteen tulee olla erityisen tarkkana. 2.5 Sisällönhallinta Sisällön tehokas hallitseminen vaatii usein erityisratkaisuja, jotka ovat riippuvaisia sisällön luonteesta ja siitä tavasta, jolla sisältöä halutaan hyödyntää. Näistä seikoista johtuen ei mitään yleisiä suuntalinjoja ole sisällönhallintaa ajatellen syntynyt, ja lisäksi sisällönhallinnasta käytettävä termistö ja käsitteet saattavat vaihdella erilaisten järjestelmien kesken [9], [22, s. 2]. Tässä kohdassa perehdytään sisällönhallintaan yleisesti ja pyritään määrittelemään siihen liittyviä käsitteitä. Mauthe ja Thomas [22, s. 4] asettavat sisällön (engl. contet) käsitteelle seuraavan merkityksen: sisältö voi olla mitä tahansa audiovisuaalista, visuaalista, äänimuotoista tai tekstuaalista tietoa. Jos sisällön käsitettä tarkastellaan sen esittämisen näkökulmasta, voi tällä sisällön esityksellä olla jokin määrätty kesto, kuten on esimerkiksi video muotoisen sisällön tapauksessa. Joidenkin sisältöjen tapauksissa, kuten esimerkiksi valokuvat, sisällön esityksellä ei ole kestoa lainkaan. Lisäksi kesto voidaan nähdä luonteeltaan myös äärettömänä, kuten esimerkiksi tapauksissa joissa sisältönä on live lähetys. Sisällönhallinnan näkökulmasta sisällön oleellisimpia ominaisuuksia ovat erityisesti sisällön olemassaolon pysyvyys ja sisällön saatavuus 1 Etäproseduurikutsu (engl. remote procedure call). Sallii ohjelman kutsua toisessa erillisessä tietokoneessa olevaa toiminnallisuutta tietoverkon välityksellä.

20 2. Taustaa 14 (engl. availability), sillä juuri näiden ominaisuuksien turvaamista voidaan pitää pohjimmaisena syynä sisällönhallintajärjestelmien tarpeellisuudelle. Webin toiminta perustuu suurimmaksi osaksi hyperlinkkeihin. Näitä linkkejä seuraamalla käyttäjät voivat selata ja päästä käsiksi haluamaansa sisältöön. Linkkien yksisuuntaisen toimintaperiaatteen vuoksi web ei kuitenkaan itsessään pysty turvaamaan sisällön pysyvyyden ja saatavuuden kaltaisia ominaisuuksia. Linkit saattavat olla rikkinäisiä, viitaten esimerkiksi poistettuun resurssiin. Linkit voivat olla myös vanhentuneita osoittaen vanhentuneisiin versioihin sisällöstä, tai sijainteihin joissa ei haluttua sisältöä enää ole saatavilla. Lisäksi linkit saattavat toimia vain ajoittain, esimerkiksi tilanteissa joissa sisältöä ylläpitävä palvelinkone ei ole aina päällä tai yhteydessä verkkoon. Linkkeihin liittyvät epävakaudet ovat erityisen ongelmallisia muun muassa siitä syystä, ettei usein ole selvää miksi kyseinen linkki ei toimi, tai vastaavasti tätä syytä ei selkeästi ilmoiteta käyttäjälle. Linkkien epävakaudesta johtuen, webbiä yksinään voidaan pitää sisällönhallinnan näkökulmasta epävakaana ja epäluotettavana ympäristönä. Sisällön saatavuuden ja olemassaolon turvaamiseksi tarvitaankin erityisiä järjestelmiä. [22, s. 4] Sisällönhallintajärjestelmien toteutus ei mitenkään ole sidottu webin käyttämiseen. Sisällönhallintaa on tässä verrattu webbiin, sillä ajan hengen mukaisesti sovellukset pohjautuvat suurelta osin web teknologioihin, ja useimpia sovelluksia myös käytetään web selainten välityksellä. Myös tässä työssä kuvattava järjestelmä pohjautuu suuressa määrin web teknologioihin Sisältö, metatieto ja essentia Sisältö (engl. content) käsitteenä saattaa joissain tilanteissa aiheuttaa hämmennystä, eikä aina ole täysin selvää mihin sisällön käsitteellä tarkalleen ottaen viitataan. Toisinaan sisällön käsitteellä viitataan varsinaiseen tiedoston sisältöön, ja joissain tilanteissa sisällön käsitettä käytetään eräänlaisena yläkäsitteenä kuvaamaan sitä kaikkea tietoa joka yksittäiseen objektiin liittyy. Mauthe ja Thomas [22, s. 4] käyttävät kirjassaan kahden organisaation; Society of Motion Picture and Television Engineersin (SMPTE) sekä European Broadcasting Unionin (EBU), toimesta määriteltyä termistöä [1]. Tämän termistön mukaan sisältö (engl. content) koostuu metatiedosta (engl. metadata) ja eräänlaisesta tiedon ytimestä tai olemuksesta, josta he käyttävät termiä essentia (engl. essence). Filosofiassa tämä termi kuvaa sen attribuutin, tai joukon attribuutteja, jotka määrittelevät mikä jokin objekti pohjimmiltaan on. Mauthe ja Thomas [22, s. 4] määrittelevät kyseisen termin seuraavasti: "essentia tässä kontekstissa on raaka ohjelmallinen materiaali itsessään, esitettynä kuvin, äänin, tekstein, videoin ja niin edelleen". Essentia pitää näin ollen sisällään varsinaisen informaation koodatussa muodossa. Mauthe ja Thomas lisäävät, että toisinaan tähän sisällön olemukseen tai ytimeen viitataan termillä

21 2. Taustaa 15 media, mutta toisaalta media termiä käytettäessä on vaarana sekoitta essentia fyysisiin medioihin, kuten videonauhoihin ja CD levyihin. Tässä työssä tästä sisällön ytimestä käytetään SMPTE:n ja EBU:n määrittelemää essentia termiä. [22, s. 4] Metatieto on sisällön ydintä ja ytimen ilmentymiä kuvailevaa tietoa, joka voidaan jaotella kolmeen luokkaan: sisältöön, materiaaliin ja sijaintiin liittyvään metatietoon. Sisältöön liittyvä metatieto voi muodoltaan olla formaalia dataa, kuten esimerkiksi sisällön otsikko tai esityksen pituus. Sisältöön liittyvää metatietoa voidaan käyttää hyväksi myös sisällön indeksoinnissa esimerkiksi avainsanojen muodossa. Lisäksi sisältöön littyvän metatiedon avulla voidaan määritellä käyttöoikeuksiin liittyvää informaatiota. [22, s. 4] Materiaaliin liittyvän metatiedon avulla voidaan esimerkiksi kuvailla sisällön saatavuutta erilaisissa formaateissa tai antaa käytettyyn koodaustapaan liittyvää informaatiota. Sijaintiin liittyvä metatieto sisältää yleensä informaatiota sisällön jakelusta, kuten esimerkiksi sisällöstä luotujen kopioiden lukumäärä. [22, s. 4] Sisällönhallintajärjestelmien ominaisuuksia Sisällönhallintajärjestelmäksi (engl. content management system, CMS) kutsutaan sellaista järjestelmää joka hallinnoi sisältöä kokonaisuudessaan. Näin ollen sisällönhallintajärjestelmän tulee hallinnoida, sekä sisältöön liittyvää metatietoa että sisällön ydintä, essentiaa. [22, s. 10] Seuraavaksi on esitetty koostettuna useiden sisällönhallintajärjestelmien kuvauksissa esitettyjä oleellisimpia ominaisuuksia ja vaatimuksia, joihin myös tässä työssä kuvaillun järjestelmän suunnittelussa on pyritty kiinnittämään huomiota. Nämä ominaisuudet on numeroitu, jotta niihin voidaan myöhemmin viitata. Ominaisuudet eivät numeroinnista huolimatta ole tärkeysjärjesteyksessä. 1. Loppukäyttäjien ja tietosisällön vuorovaikutuksen näkökulmasta sisältö tulee sijoittaa välittömästi luomisen jälkeen sellaiseen paikkaan joka on turvallinen, ja josta sisältöä voidaan hakea ja käyttää (engl access) ajasta ja sijainnista riippumatta [31]. Sisällönhallintajärjestelmän tulee huolehtia sisällön koko elinkaaresta [9]. 2. Tietosisältöä tulisi olla helppoa etsiä ja navigoida [31]. Curtis et al. kirjoitavat, että tätä ominaisuutta voidaan pitää jokaisen sisällönhallintajärjestelmän kannalta kaikkein tärkeimpänä ominaisuutena [9]. 3. Sisällönhallintajärjestelmän tulee järjestelmän fyysisen rakenteen kannalta valvoa sitä, mistä sisältöön viitataan, ja sijoittaa sisältö sitä käyttävien järjestelmien kannalta optimaaliseen paikkaan [8].

22 2. Taustaa Mahdollisimman paljon metatietoa tulee tuottaa ja liittää sisältöön heti sisällön luonnin yhteydessä [9]. 5. Sisällönhallintajärjestelmän tulee tukea sisällön kuvailemista mielivaltaisen ja heterogenisen metatiedon avulla [7]. 6. Sisällönhallintajärjestelmän tulee toimia heterogenisessä ympäristössä siten, että se tarjoaa kaikille resursseille yhtenäisen rajapinnan [8]. 7. Hajautetun sisällönhallintajärjestelmän tulee tarjota tehokas tapa käyttää heterogenisessä tietoverkossa sijaitsevaa tietosisältöä käyttäjäkohtaisten asetusten perusteella [8]. Useimmat yllä esitetyistä seikoista toistuvat erilaisten sisällönhallintajärjestelmien kuvauksissa, mutta painotus näiden välillä vaihtelee hallittavan sisällön tyypin ja käyttötarkoituksen mukaan. Hajautettu heterogeeninen järjestelmä tuo mukanaan lisäksi joukon omia ongelmiaan, jotka eivät luonnollisesti koske kaikkia sisällönhallintajärjestelmiä. Tästä syystä nämä hajautukseen seikat on esitetty yllä olevassa koosteessa viimeisenä Sisällön hakeminen ja hakutulosten esittäminen Sisällönhallintajärjestelmän tärkeimpiin ominaisuuksiin kuuluvat mekanismit, joilla digitaaliseen tietosisältöön voidaan kohdistaa mahdollisimman monipuolisia hakuja (ominaisuus 2). Ideaalisessa tapauksessa hakuja voidaan tehdä kaiken sisällöstä tuotetun metatiedon perusteella, sillä varsinaisen tiedoston sisällön tutkiminen ja hakujen tekeminen näiden tulkintojen perusteella on toisteiseksi hyvin alkeellista. Tästä syystä johtuen metatietojen pääasiallisena käyttötarkoituksena on mahdollistaa sisällön etsiminen metatietoihin kohdistettujen hakujen perusteella [22, s. 90]. Tyypillisesti sisällönhallintajärjestelmiä käyttävät asiantuntijat haluavat tehokkaan rajapinnan sisällön etsimiseen. Tällaisille käyttäjille tuleekin tarjota tapa, jolla he voivat yksityiskohtaisesti ja monipuolisesti etsiä sisältöä kaiken sisällöstä tuotetun metatiedon perusteella. Tätä rajapintaa käyttävät myös muut sisällönhallintajärjestelmää hyväkseen käyttävät sovellukset. Toisaalta taas niin sanotuilla tavallisilla käyttäjillä ei välttämättä ole taitoa, eikä halua opetella yksityiskohtaisten hakulausekkeiden kirjoittamista. Näille käyttäjille voidaankin tarjota lukuisia erilaisia tapoja sisällön etsimiseen ja selaamiseen, toteutettuina joko suoraan sisällönhallintajärjestelmän yhteyteen, tai erillisten sovellusohjelmien muodossa. [22, s ] Curtis et al. kirjoittavat, että tutkimusten mukaan käyttäjät hakevat tyypillisimmin sisältöä esimerkiksi paikkojen todellisten nimien mukaan [9]. Onkin varsin ymmärrettävää, että käyttäjät hakevat esimerkiksi kuvia Vapaudenpatsaasta käyttäen hakuehtona mielummin kohteen todellista nimeä kuin sen GPS koordinaatteja.

23 2. Taustaa 17 Sisällön etsimisen tulee olla tehokasta ja helppoa, sillä tietosisältöä ja siitä tuotettua metatietoa on useissa tapauksissa kertynyt suuria määriä (ominaisuus 2). Hakujen kohdentaminen auttaa rajaamaan pois ei toivottuja hakutuloksia. Rajaamalla haku tiettyyn osaan järjestelmän tietosisältöä, ei muita tarkentavia hakukriteerejä tarvitse erikseen tutkia jokaiselle järjestelmän resurssille. Sisällönhallinajärjestelmän tuleekin tarjota tapa, joilla hakuja voidaan rajata vain tiettyyn osaan järjestelmään tuotua sisältöä. Valmiiden web sovelluskehysten ja niiden menetelmien käyttäminen monimutkaisissa hauissa saattaa toisinaan kasvattaa suuriin sisältöjoukkioihin liittyviä pullonkauloja, sillä näitä menetelmiä ei ole suunniteltu monimutkaisten ja useista tietokannan tauluista koostuvien hakujen suorittamiseen. Käytännössä hakujen tehokkuus jää lopulta tietokannanhallintajärjestelmän ominaisuuksien, sekä näiden ominaisuuksien hyödyntämisen vastuulle. Hakutulosten esittäminen tulee huomioida sen mukaan mikä on hakutulosten käyttötarkoitus. Järjestelmän toimiessa välikerroksena, jolloin sen tehtävänä on tarjota rajapinta tietosisällön etsimiseen, tulee hakutulokset esittää sellaisessa muodossa, että järjestelmää käyttävien asiakasohjelmien on mahdollista hyödyntää hakutuloksia mahdollisimman tehokkaasti. Mikäli hakutuloksia käyttää ihminen, tulee hakutulokset esittää hänelle mahdollisimman selkeässä ja käytettävässä muodossa, sekä tarjota mahdollisuuksia hakutulosten järjestämiseen Metatietojen tuottaminen Sisällöstä tuotettu metatieto vaihtelee, ja määräytyy pääasiassa tietotyypin (MIME type) mukaan, mutta kaikella yksittäisellä sisällöllä voidaan kuitenkin katsoa tyypistä rippumatta olevan samankaltaiset perustiedot, kuten nimi, hakemistopolku, viimeisin muokkaamisajankohta, useimmissa tapauksissa tiedoston koko, sekä versiointiin liittyvät tiedot. Näistä metatiedoista käytetään tässä työssä termiä initiaalimetatiedot, sillä termillä halutaan korostaa, että juuri näiden metatietojen joukko määrittelee, että yksittäinen sisältö on olemassa sisällönhallintajärjestelmässä. Toisaalta voidaan myös ajatella, että initiaalimetatiedot syntyvät useimmissa tapauksissa ikään kuin automaattisesti samalla hetkellä kuin sisältö itsessäänkin syntyy. Yllä esitetyn listan ominaisuuden 4 mukaan sisällöstä tulee tuottaa mahdollisimman paljon metatietoa, ja nämä metatiedot tulisi lisäksi tuottaa välittömästi sisällön luomisen jälkeen. Curtis et al. ovat ratkaisseet tämän vaatimuksen kehittämällä erillisen työkalun, jonka avulla sisällöstä voidaan poimia metatietoja [9]. Kyseinen työkalu toimii puoliautomaattisesti, sillä myös heidän mukaansa sisältöä automaattisesti tutkimalla ei vielä voida luotettavasti tuottaa kaikkea sitä metatietoa, jonka perusteella käyttäjät haluavat sisältöä etsiä. Tämän automaattisen toiminnan lisäksi työkalu tarjoaa tavan metatietojen syöttämiseksi manuaalisesti ihmiskäyttäjien

24 2. Taustaa 18 toimesta. [9] Erilaiset algoritmit saattavat tarjota mahdollisuuden metatietojen tuottamiseen. Tällä hetkellä tehdään paljon tutkimusta esimerkiksi kasvojentunnistusalgoritmien kehittämiseksi [12]. Näitä algoritmeja käyttäen voitaisiin kuviin liittää tietoja esimerkiksi siitä, kuinka monta henkilöä niissä esiintyy, sekä mahdollisesti joissain tilanteissa voitaisiin myös liittää näihin kuviin tieto siitä, keitä nämä kuvissa esiintyvät henkilöt ovat. Erilaisten kirjastojen avulla voidaan esimerkiksi kuvista tutkia kameroiden niihin mahdollisesti tallentamia EXIF tietoja. Mikäli kamerassa tai kuvan tallentaneessa laitteessa on ollut GPS paikannin, on kuvien EXIF tietoihin voitu tallentaa myös paikkatietoja. Useimmissa kameroissa GPS paikannusta ei kuitenkaan ole, joten mikäli paikkatieto kuviin ja muihin tiedostoihin halutaan liittää, täytyy tämä tieto syöttää jollain toisella tavalla. Useissa nykyaikaisissa älypuhelimissa on sisäänrakennettuna GPS vastaanotin, jota voidaan hyödyntää tässä tarkoituksessa. Tämän lisäksi älypuhelimen sijaintia voidaan yrittää paikantaa myös IP osoitteeseen perustuvien menetelmien avulla, joskaan näiden menetelmän avulla saatu paikkatieto ei aina ole kovin tarkkaa. Sisällön essentiaa ohjelmallisesti tutkimalla voidaan kuitenkin saada selville vain hyvin rajoittunut määrä metatietoa, jota voitaisiin todellisuudessa hyödyntää sisällön etsimisessä [9]. Kuten jo aikaisemmin todettiin, haluvat käyttäjät tyypillisesti etsiä sisältöä siihen liittyvien todellisten nimien perusteella. Tämän tiedon liittäminen sisältöön automaattisesti on kuitenkin toistaiseksi lähes mahdotonta. Mikäli sisältöä tuottaa mobiililaite, jonka GPS koordinaatit ovat selvillä, voidaan tämä tieto yrittää muuntaa osoitetiedoiksi joidenkin palveluiden avulla. Tällaisen rajapinnan tarjoaa esimerkiksi Google Geocoding rajapinta [34]. Nämä osoitetiedot voidaan tämän jälkeen liittää kyseisessä sijainnissa tuotettuun sisältöön, kuten esimerkiksi älypuhelimella otettuihin valokuviin. Käyttäjät eivät kuitenkaan useimmissa tapauksissa halua etsiä sisältöä osoitetietojen perusteella, vaan sisältöön tulee ennemmin voida liittää jokin konkreettista paikkaa kuvaava nimi. Tämä konkreettisten paikkojen nimien lisääminen voidaan tehdä käyttäjien toimesta. Käyttäjät voivat esimerkiksi lisätä tageja, jotka ovat eräänlaisia sisältöä kuvailevia hakusanoja. Kun sisältöön on kertynyt tageja, voidaan sisältöjen metatietojen välillä etsiä yhtäläisyyksiä ja havaittujen yhtäläisyyksien perusteella voidaan käyttäjille ehdottaa tagien lisäämistä sellaiseen sisältöön, josta ne vielä puuttuvat, mutta johon tagit järjestelmän havaitsemien yhtäläisyyksien perusteella kuitenkin saattaisivat sopia. Mikäli prosessia halutaan entisestään automatisoida, on mahdollista että sisällönhallintajärjestelmä lisää tageja automaattisesti. Tällöin kuitenkin käyttäjät saattavat joutua poistamaan virheellisesti lisättyjä tageja. Toisaalta järjestelmää voidaan edelleen kehittää oppimaan virheellistä tagien

25 2. Taustaa 19 lisäämisistä, jolloin näiltä on mahdollista tulevaisuudessa välttyä tehokkaammin. Amato et al. kirjoittavat, että sisällönhallintajärjestelmän tulee tukea sisällön kuvailemista mielivaltaisen metatiedon perusteella [7]. Lisäksi tämä metatieto saattaa olla heterogeenistä, millä tarkoitetaan sitä, ettei kaikella sisällöllä välttämättä ole samaa metatietotyyppiä olevia metatietoja, vaikka sisällöt muuten vaikuttaisivatkin hyvin samankaltaisilta (ominaisuus 5). Vaikka tagit tarjoavatkin käyttäjille tavan kuvailla ja merkata sisältöä hieman monipuolisemmin, saattaa sisällön hakeminen pelkästään tagien perusteella tuoda hakutuloksiin mukaan myös ei toivottua sisältöä 2. Ongelma johtuu osaltaan siitä, että tagi itsessään määrittelee vain yhden metatietotyypin, jolle kukin käyttäjä voi antaa haluamansa merkityksen. Toiset voivat käyttää tageja esimerkiksi liittäessään sisältöön paikkatietoa, toiset taas kuvaillessaan valokuvassa esiintyviä asioita 3. Mikäli sisältöä halutaan kuvata monipuolisesti, ja lisäksi halutaan, että sisällön etsiminen toimii tarkasti, tulee käyttäjien voida lisätä järjestelmään myös omia metatietotyyppejään. Tällöin sisällön hakemisen yhteydessä voidaan määrittää myös se minkä tyyppistä metatietoa hakutermin halutaan vastaavan Sisällön saatavuus Aikaisemmin kuvailtiin sisällönhallintajärjestelmän erääksi tärkeimmäksi tehtäväksi huolehtia sisällön saatavuudesta ja olemassaolon pysyvyydestä. Hajautetussa pilviympäristössä nämä seikat saavat uusia ulottuvuuksia, sillä tyypillisesti käyttäjät haluavat saada heitä kiinnostavan sisällön käsiinsä, eivätkä ole kiinnostuneita siitä, missä sisältö todellisuudessa sijaitsee. Hajautetussa sisällönhallintajärjestelmässä sisällön essentia voi näin olle sijaita missä tahansa järjestelmän osassa, vaikka sisällön metatiedot olisivatkin keskitetysti saatavilla jostain järjestelmän tietystä osasta. Metatietojen hallinnan voidaan näin ajatella olevan eräänlainen avaintekijä, joka yhdistää järjestelmän osat keskenään [9]. Hajautetun ympäristön koostuminen heterogeenisista laitteista, jotka yhä useammin ovat mobiililaiteita, tuo mukanaan hyvin haastavia ongelmia, jotka vaikuttavat ennen kaikkea sisällön saatavuuteen. Mobiililaitteiden suhteellisen hitaat verkkoyhteydet saattavat joissain tilanteissa vaikeuttaa sisällön välittämistä eteenpäin. Tästä johtuen sisällönhallintajärjestelmän tulisikin sijoittaa sisältö, tai sisällön essentia sellaiseen paikkaan, josta sitä voidaan mahdollisimman tehokkaasti käyttää (ominaisuudet 1 ja 3). Mobiililaitteet eivät aina ole yhteydessä verkkoon, sillä jatkuva yhteys internettiin saattaa kuluttaa näiden laitteden akkua huomattavasti, ja käyttäjät saattavatkin ajoittain kytkeä yhteydet pois käytöstä. Lisäksi yhteydet saat- 2 Käyttäjän lisätessä valokuvaan tagin suvi, voidaan tämän ymmärtää tarkoittavan esimerkiksi käyttäjän Suvi nimistä tyttöystävää, mutta toisaalta myös vaikkapa Suomen kesää. 3 Mitäpä yhteistä on vaikkapa porkkanalla ja Hervannalla?

26 2. Taustaa 20 tavat olla kalliita käyttää, sillä niiden hinnoittelu voi joissain tilanteissa perustua siirrettyihin datamääriin. Toisaalta kiinteä hinta saattaa sisältää datan siirtoa jonkin ennalta sovitun suuruisen määrän, ja ylimenevä osuus saattaa kasvattaa käyttökustannuksia. Hinnoitteluun liittyvät ongelmat ovat kuitenkin vähitellen korjaantumassa kiinteähintaisten mobiililaajakaistayhteyksien ansiosta. Sisällön saatavuuteen voivat osaltaan vaikuttaa myös erilaisissa ympäristöissä käytettävät tietoturvaratkaisut. Esimerkiksi palomuurit saattavat joissain tilanteissa estää HTTP protokollan välityksellä kulkevaa liikennettä, tai liikenne saattaa joissain organisaatioissa estyä verkon rakenteesta johtuen. Eräs menetelmä mobiililaitteista peräisin olevan sisällön saatavuuden turvaamiseksi on, että laite päivittää verkkostatuksensa sellaiselle sisällönhallintajärjestelmän osalle, joka on varmasti aina saavutettavissa. Tämän tiedon pohjalta voidaan tehdä päätelmiä sisällön saatavuudesta, ja näin ollen antaa sisällöstä kiinnostuneille käyttäjille selkeää palautetta. Lisäksi statusinformaatio voidaan yhdistää sisällön hakutyökaluihin, jolloin voidaan etsiä vain sellaista sisältöä joka on juuri kyseisellä hetkellä saatavissa. Sisällön essentian saatavuuden turvaamiseksi, voidaan essentiaa varastoida sellaiseen sisällönhallintajärjestelmän osaan, josta on nopeat verkkoyhteydet, ja joka on aina yhteydessä verkkoon. Tässä työssä tästä sisällönhallintajärjestelmän osasta käytetään nimitystä välimuisti. Termillä halutaan korostaa sitä, että tätä järjestelmän osaa käytetään ensisijaisesti sisällön essentian väliaikaiseen varastoimiseen. Mobiililaitteiden sisältöä voitaisiin kuitenkin säilyttää välimuistissa pidempiäkin aikoja, esimerkiksi sen mukaan, miten usein tätä essentiaa halutaan käyttää. Ominaisuuksien 1 ja 3 mukaan sisältö tulisi sijoittaa järjestelmän fyysisen rakenteen kannalta optimaaliseen paikkaan. Metatietojen säilyttäminen keskitetyllä palvelimella takaa sen, että tieto sisällön olemassaolosta on aina saatavilla, vaikka sisällön essentia ei olisikaan tietyllä ajanhetkellä saatavissa. Essentian saatavuuden parantamiseksi sisällönhallintajärjestelmä voi tarjota mekanismeja, joiden avulla käyttäjät voivat pyytää järjestelmältä informaatiota, kun sisällön essentian saatavuudessa tapahtuu muutoksia. Toisaalta sisällönhallintajärjestelmä voi asettaa puskuriin käyttäjien tekemiä pyyntöjä sisällön essentian noutamiseksi. Kun se sisällönhallintajärjestelmän osa jossa essentia sijaitsee tulee jälleen saataville, voidaan pyynnöt essentian siirtämiseksi välittää edelleen Sisällön versiointi Tietokoneiden ja mobiililaitteiden kasvaneet tiedonsäilömiskapasiteetit ovat mahdollistaneet sen, että sisällöstä voidaan muokkaamisen yhteydessä luoda uusia versioita sen sijaan, että vanha sisältö korvattaisiin aina uudella. Osaltaan versiointi saattaa kuitenkin nopeastikin lisätä sisällönhallintaan liittyviä ongelmia: mikäli sisällön

27 2. Taustaa 21 hallitseminen manuaalisesti on hankalaa, ei useiden samasta sisällöstä tuotettujen versioiden hallitseminen manuaalisesti todennäköisesti ainakaan paranna tilannetta. Usein käyttäjät pyrkivät nimeämään sisältöä jonkin systemaattisen käytännön mukaisesti, antaen tiedostoille kuvaavat ja loogiset nimet. Lisäksi nimeen liitettävän versioninformaation avulla voidaan yrittää pitää kirjaa muun muassa siitä, mikä on uusin versio. Tyypillisesti käyttäjät kuitenkin jossain vaiheessa poikkevat tämänkaltaisista systemaattisista käytännöistä, minkä seurauksena näistä käytännöistä on helppoa luopua kokonaan. Toisaalta digitaalikamerasta valokuvia tuotaessa saattaa kameran muistikortti sisältää valokuvia esimerkiksi puolen vuoden ajalta erilaisista tapahtumista, jotka on digitaalikameran toimesta tyypillisesti nimetty päivämäärän tai jouksevan tunnisteen mukaan. Sisällön systemaattinen nimeäminen jälkikäteen on haastavaa ja aikaa vievää, ja saattaa näin ollen jäädä tekemättä. Tämän seurauksena sisällön systemaattinenkin hallitseminen manuaalisesti saattaa nopeasti menettää merkityksensä, mikäli käytäntöjä ei sovelleta aina kaikelle sisällölle. Ominaisuuden 4 mukaan metatiedot sisältöön ja näin ollen myös sisällöstä tuotettuihin versioihin liittyen tulisikin liittää automaattisesti ja heti luomisen yhteydessä. Hajautettu järjestelmä ja mahdollisuus versioida sisältöä tuovat sisällönhallintaan ja sisällön etsimiseen vielä uuden ulottuvuuden. Useasta fyysisestä laitteesta koostuvassa ympäristössä sisältö voi olla esimerkiksi tuotettu yhdellä laitteella, jossa myös alkuperäinen versio sisällöstä on tallessa. Tämän jälkeen sisältöä on voitu joko tiedoston alkuperäisen omistajan, tai jonkin muun henkilön toimesta muokata toisella laitteella, jolloin muokattu versio saattaa olla talletettuna toisaalle. Näin ollen myös alkuperältään sama sisältö voi järjestelmän fyysisen rakenteen näkökulmasta olla hyvin hajanaisesti sijoittunut eripuolille järjestelmää. Sisällön versiointia ja näiden versioiden hallintaa helpottamaan on kehitetty useita työkaluja, kuten esimerkiksi ohjelmistojen kehityksessä käytettävät Subversion [32] ja Git [15]. Näiden työkalujen avulla useat käyttäjät voivat samanaikaisesti käsitellä sisältöä, jotka versionhallintajärjestelmä muutosten tekemisen jälkeen pyrkii yhdistämään (engl. merge). Tyypillisesti muutosten yhdistäminen voidaan suorittaa lähinnä vain tekstimuotoiselle sisällölle. Sisällönhallintajärjestelmän ja versionhallintajärjestelmän erot liittyvät suuressa määrin niiden käyttötarkoituksiin. Sisällönhallintajärjestelmät keskittyvät pääasiassa sisällön kokonaisvaltaiseen hallitsemiseen, kun taas versionhallintajärjestelmät on tyypillisesti kehitetty hieman erikoistuneempia tarpeita ajatellen.toisaalta useat sisällönhallintajärjestelmät myös huolehtivat sisällön versioinnista. Sisällön versioinnin voidaan ajatella vaikuttavan osaltaan myös sisällön saatavuuteen, sillä tallettamalla sisällöstä muokkauksen yhteydessä aina uusi versio korvaamatta edellisiä versioita, voidaan käyttäjille taata, että heillä on saatavilla juuri sama versio sisällöstä, kuin mitä heillä oli aikaisemminkin. Näin olisi mahdotonta

28 2. Taustaa 22 toimia, mikäli sisältöä ei versioitaisi, sillä sisältö oltaisiin voitu korvata uudemmalla versiolla tai poistaa kokonaan. Toisaalta versioinnin vaikutuksesta sisällön muokkaaminen saattaa estyä, sillä vanhan version muokkaaminen tarkoittaa käytännössä aina uuden version luomista, eikä tietyn objektin nimenomaista muokkaamista. Versioinnin voidaan katsoa kerryttävän sisällöstä tuotettavan metatiedon määrää, sillä useat metatiedot ovat vahvasti kytköksissä sisällön essentiaan, ja saattavat näin ollen vaihdella versioittain essentian muuttuessa (ominaisuus 4). Tässä työssä kuvattavan järjestelmän tapauksessa on merkityksellistä ymmärtää, se miten sisältö jakautuu eri versioihin metatietojen tasolla, sillä VisualREST järjestelmä keskittyy suuressa määrin juuri metatietojen tuottamiseen ja ylläpitämiseen. Myöhemmin on kuvattu se, miten sisällöstä ja sen versioita tuotetettu metatieto on talletettuna ja miten näitä tiedot käytetään hyväksi Sisällön oikeuksien hallinta Ominausuuden 7 mukaan hajautetun sisällönhallintajärjestelmän tulee tarjota tehokas tapa käyttää sisältöä käyttäjäkohtaisten asetusten perusteella. Käyttäjäkohtaisia asetuksia on mahdollista valvoa joko asiakasohjelman, tai palvelinohjelmiston päässä. Usein käyttäjäkohtaisia asetuksia on kuitenkin luonnollista valvoa palvelinohjelmiston puolella, sillä tämänkaltaisissa hajautetuissa sisällönhallintajärjestelmissä sisältöä tyypillisesti käytetään juuri palvelimen välityksellä. Palvelimen puolella toteutettu käyttäjäkohtaisten asetusten tallettaminen toteutetaan tyypillisesti käyttäjäprofiilien avulla. Ensimmäistä kertaa järjestelmää käyttäessään käyttäjät rekisteröityvät palvelun käyttäjiksi luomalla itselleen käyttäjätilin. Tilin luonnin yhteydessä käyttäjät valitsevat tyypillisesti itselleen käyttäjätunnuksen, jonka tulee olla yksikäsitteinen järjestelmän kontekstissa. Myöhemmin tätä tunnusta voidaan käyttää muun muassa käyttäjän tunnistautumiseen (engl. authentication) tai esimerkiksi resursseihin viittaamiseen. Lisäksi voidaan ajatella, että käyttäjät tietyllä tapaa laajentavat käyttäjäprofiiliaan esimerkiksi muokkaamalla siihen liittyviä asetuksia, sekä tuomalla sisällönhallintajärjestelmään uutta sisältöä joka liitetään heidän käyttäjäprofiileihinsa. Käyttäjäkohtaiset asetukset käsittävät tyypillisesti sisällön käyttöoikeuksien hallinnan. On lunnollista, että käyttäjät haluavat säädellä sisältöön liittyviä käyttöoikeuksia, sillä kaikkea sisältöä ei useinkaan haluta jakaa kaikkien järjestelmän käyttäjien kesken. Tästä syystä käyttäjille tulisi tarjota helppokäyttöisiä ja monipuolisia tapoja sisällön käyttöoikeuksien määrittämiseksi. Lisäksi käyttöoikeuksien määrittämisen tulisi olla tehokasta, sillä tyypillisesti järjestelmään on rekisteröitynyt hyvin suuri joukko käyttäjiä, ja näistä käyttäjistä vain hyvin pieni joukko on sellaisia, joiden kesken sisältö halutaan jakaa. Toisaalta käyttäjä on saattanut tuoda huomattavan suuren joukon sisältöä osaksi järjestelmää, mistä johtuen on ymmärrettävää

29 2. Taustaa 23 etteivät käyttäjät ole tyypillisesti halukkaita määritelemään manuaalisesti ja yksittäin kaikkia niitä käyttäjiä, joiden kesken sisältö halutaan jakaa. Eräs manuaalisen työn määrää vähentävä ratkaisu tähän ongelmaan ovat käyttäjien henkilökohtaisesti määrittelemät käyttäjäryhmät. Vaikka tämä ratkaisu ei kokonaan poistakaan manuaalisesta käyttöoikeuksien määrittämisestä aiheutuvaa työtaakkaa, voidaan tätä työtaakkaa kuitenkin sen avulla huomattavasti keventää: sisältöön voidaan kerralla antaa käyttöoikeus suurelle käyttäjien joukolle. Näin olle riittää, että käyttäjä on vain kerran joutunut manuaalisesti määrittelemään sen, mihin käyttäjäryhmään tietyt käyttäjät kuuluvat. Esimerkkejä käyttäjäryhmistä voisivat olla esimerkiksi kaverit, perhe, työkaverit ja niin edelleen. Käyttöoikeuksien asettamista on myös mahdollista osaltaan automatisoida erilaisten politiikoiden avustuksella. Politiikoiden avulla voidaan etukäteen esimerkiksi määritellä se, minkälaisia käyttöoikuksia jollekin tietyn tyyppiselle sisällölle annetaan automaattisesti, ilman käyttäjältä vaadittavaa manuaalista työtä. Automaattisen prosessin vaarana piilee kuitenkin se, että sisällölle annetaankin vahingossa vääränlaiset käyttöoikeudet. Sisältöön, niin kuin myös muihin järjestelmän resursseihin liittyvien käyttöoikeuksien tarkastelemiseksi, sisällönhallintajärjestelmän tulee tarjota tapa, jolla käyttäjät voivat tunnistautua. Mikäli järjestelmää käyttävät lisäksi toiset sovellukset, tulee näille tarjottavan asiakasrajapinnan toteuttaa jokin tapa, jolla myös sovellusohjelmien on mahdollista tunnistautua.

30 24 3. JÄRJESTELMÄN YLEISKUVAUS Hajautetut järjestelmät koostuvat useista pienemmistä osajärjestelmistä, jotka kommunikoivat keskenään ja hyödyntävät toistensä resursseja. VisualREST koostuu resurssien metatietojen välittämiseen ja ylläpitämiseen käytettävästä palvelinohjelmistosta, sekä näitä metatietoja tuottavista ja sisällön essentiaa varastoivista asiakasohjelmista, joista käytetään nimitystä tietosäiliöohjelma. Yhdessä nämä osajärjestelmät huolehtivat lisäksi varsinaisten sisältöjen essentioiden välittämisestä niitä hyödyntäville muille järjestelmille. Kuva 3.1: VisualREST järjestelmän yleinen rakenne. Kuvassa 3.1 on hahmoteltu järjestelmän pilvimäistä rakennetta. Tietosäiliöohjelmaa suorittavat laitteet liitetään yhteen VisualREST palvelimen välityksellä, minkä seurauksena syntyy laitteiden sisällöstä koostuva sisältöpilvi. Tätä pilveä VisualREST palvelin hallinnoi, toimien eräänlaisena porttina tämän pilven tarjoamaan sisältöön.

31 3. Järjestelmän yleiskuvaus 25 Tässä luvussa on keskitytty kuvaamaan pääasiassa palvelinohjelmiston toimintaa yleisesti. Lisäksi kuvaillaan niitä vaatimuksia, jotka järjestelmä asettaa metatietietoja tuottavalle ja sisällön essentiaa varastoivalle tietosäiliöohjelmalle. Tietosäiliöohjelman voidaankin nähdä olevan eräänlainen toimintojen joukko, jotka asiakasohjelman tulee toteuttaa, että se voisi tuoda sisältöä osaksi VisualREST järjestelmää. Lisäksi kuvaillaan tietosäiliöohjelman esimerkkitoteutusta ja yhteistoimintaa palvelinohjelmiston kanssa. Palvelinohjelmiston rajapinta noudattaa REST suunnitteluperiaatteita, mikä löyhän sidonnan ansiosta mahdollistaa tietosäiliöohjelman lisäksi myös muiden, hyvinkin erilaisten asiakasohjelmien toteuttamisen. Asiakasohjelmat voivat lukea, muokata, päivittää ja poistaa palvelinohjelmiston ylläpitämää, sisällöstä tuotettua metatietoa. Lisäksi asiakasohjelmat voivat noutaa varsinaista sisällön essentiaa palvelinohjelmiston välityksellä. 3.1 Palvelinohjelmiston yleiskuvaus Tässä kohdassa tutustutaan VisualREST palvelinohjelmiston toimintaan yleisellä tasolla. Kuten aikaisemmin on jo tuotu esiin, on VisualREST palvelinohjelmiston pääasiallisena tarkoituksena varastoida sisällöstä tuotettua metatietoa ja tarjota tehokas rajapinta sisällön etsimiseen metatietoihin perustuen. Palvelinohjelmiston tarjoaman REST rajapinnan välityksellä sisältöön liittyviä metatietoja voidaan myös lisätä, muokata ja poistaa. Lisäksi REST rajapintaa käyttäen voidaan luoda, muokata ja poistaa järjestelmän resursseja. Resurssit voivat metatietojen ohella olla esimerkiksi käyttäjiä, laitteita, käyttäjäryhmiä, tai esimerkiksi tietyn käyttäjäryhmän oikeus tiettyyn sisältöön. Tuomalla sisällön metatiedot VisualREST palvelimelle, mahdollistetaan samalla myös sisällön jakaminen julkisesti muiden järjestelmän käyttäjien kesken. Sisällön etsimisen tehostamiseksi ja turhien hakutulosten karsimiseksi VisualREST mahdollistaa sisällön kuvailemisen mahdollisimman monipuolisen ja heterogeenisen metatiedon avulla (ominaisuus 5). Tämä on tehty mahdolliseksi siten, että käyttäjät voivat halutessaan lisätä järjestelmään omia metatietotyyppejään, ja kuvailla sisältöä niiden avulla. Järjestelmään lisätyt metatietotyypit ovat julkisia, minkä ansiosta myös muiden käyttäjien on mahdollista käyttää näitä tyyppejä kuvaillessaan metatietoja. Sisältöä voidaan lisäksi suojata siten, että siihen liittyvät käyttöoikeudet on rajattu vain tietyille käyttäjäryhmille. Tällä tavoin suojatun sisällön olemassaoloa ei paljasteta ennalta määriteltyjen käyttäjäryhmien ulkopuolelle jääville käyttäjille. VisualREST palvelinohjelmisto tarjoaa järjestelmän käyttämiseen sovellusohjelmille tarkoitetun ja jo aikaisimmin mainitun REST rajapinnan lisäksi myös web käyttöliittymän. Tämän käyttöliittymän ansiosta käyttäjien on mahdollista etsiä sisältöä käyttäen hyväksi erilaisia hakulomakkeita. Lisäksi käyttäjät voivat muokata joitain sisältöön liittyviä asetuksia sekä muodostaa käyttäjäryhmiä. Näin ollen

32 3. Järjestelmän yleiskuvaus 26 Kuva 3.2: Kuvakaappaus palvelinohjelmiston web käyttöliittymästä. Web käyttöliittymä toimii myös eräänlaisena hallintapaneelina, joilla käyttäjät voivat muokata käyttäjäprofiiliinsa liittyviä asetuksia. Kuvassa 3.2 on kuvakaappaus VisualREST palvelinohjelmiston tarjoamasta web käyttöliittymästä, jonka avulla voidaan muun muassa hakea sisältöä ja selata hakutuloksia. Kuvan ylälaidassa on nähtävissä kentät joiden avulla käyttäjät voivat lisätä tarkentavia hakutermejä mukaan kyselyyn. Käyttäessään web käyttöliittymää hakutulokset tarjotaan käyttäjille HTML muodossa. Esimerkki hakutulosten esittämisestä HTML muodossa on nähtävissä kuvassa 3.2. VisualREST järjestelmän pääasiallinen käyttötarkoitus on kuitenkin toimia eräänlaisena välikerroksena toisille sovellusohjelmille. Tästä syystä hakujen tulokset tarjotaan myös Atom syötteiden muodossa, joka osaltaan mahdollistaa useiden jo olemassaolevien sovellusten käyttämisen. Useimmat web selaimet, ja jotkin sähköpostiohjelmat tukevat Atom syötteitä joko suoraan tai asennettavien lisäosien (engl. plugin) avulla. Lisäksi on olemassa suuri joukko valmiita syötteiden lukemiseen tarkoitettuja web-sovelluksia ja työpöytäsovelluksia. Kuvassa 3.3 on kuvakaap-

33 3. Järjestelmän yleiskuvaus 27 Kuva 3.3: Kuvakaappaus hakutuloksista Atom syötteen muodossa Safari web selaimen feed lukijassa esitettynä. paus hakutulosten esittämisestä Atom syötteen avulla Safari web selaimen RSS syötteenlukijaa käyttäen. Liitteessä B on esimerkin vuoksi esitetty yksittäisen tiedoston sisältävän haun tulokset Atom syötteenä. 3.2 Tietosäiliöohjelman yleiskuvaus Seuraavaksi tutustutaan tietosäiliöohjelman funktioon VisualREST järjestelmässä. Tietosäiliöohjelman nimitysellä viitataan asiakasohjelman kykyyn tuoda sisältöä osaksi VisualREST järjestelmän tarjoamaa pilvipalvelua. Näin ollen tietosäiliöohjelman voivat toteuttaa myös muutkin asiakasohjelmat, kuin tässä työssä kuvattava tietosäiliöohjelma. Tietosäiliöohjelma voidaan lisäksi myös toteuttaa erilaisten toimintaperiaatteiden mukaan kuin mitä tässä työssä kuvattava esimerkkitoteutus toimii. Tästä huolimatta tietosäiliöohjelman tulee täyttää joukko vaatimuksia, jotka VisualREST järjestelmä sille yleisen toimintalogiikkansa ja toimintafilosofiansa myötä asettaa. Nämä vaatimukset on kuvattu tarkemmin seuraavassa alakohdas-

34 3. Järjestelmän yleiskuvaus 28 sa. Voidakseen toteuttaa sille asetetut vaatimukset, tietosäiliöohjelman tulee lisäksi toteuttaa taulukoissa kuvattu tietosäiliöohjelman XMPP rajapinta. Kuva 3.4 esittää tietosäiliöohjelmaa VisualREST järjestelmän asettamien vaatimusten näkökulmasta. Kuva 3.4: Tietosäiliöohjelman yleiset vaatimukset Vaatimukset tietosäiliöohjelmalle Tässä työssä kuvattava tietosäiliöohjelma on eräänlainen esimerkkitoteutus siitä, miten sisältöä voidaan tuoda osaksi VisualREST järjestelmää. Jotta sisällönhallintajärjestelmästä saataisiin mahdollisimman suuri hyöty ja sisällöltään kattava, on siihen voitava tuoda sisältöä mahdollisimman monista ja erilaisista lähteistä. Tästä syystä seuraavaksi kuvataan ne vaatimukset, jotka järjestelmä asettaa tietosäiliöohjelman toteuttamiselle. 1. Tietosäiliöohjelman tulee tukea REST suunnitteluperiaatteiden asettamia vaatimuksia HTTP protokollan ominaisuuksiin liityen. Ohjelman tulee näin ollen pystyä tekemään HTTP pyyntöjä käyttäen GET, PUT, POST ja DELETE metodeja. 2. Ohjelman tulee osata laskea taulukossa 4.2 kuvatut REST rajapinnan autentikoitumisparametrit. 3. Ohjelman tulee osata rekisteröidä itsensä VisualREST palvelimelle ja säilyttää rekisteröinnin yhteydessä luotuja tietoja.

35 3. Järjestelmän yleiskuvaus Ohjelman tulee toteuttaa taulukoissa kuvattu XMPP rajapinta, sekä siihen liittyvä toiminnallisuus. Lisäksi ohjelman tulee tarkkailla rajapintaan tulevia viestejä aktiivisesti. 5. Ohjelman tulee käyttää sisällön varastoimiseen Git versionhallintaohjelmaa, tai huolehtia sisällön versioinnista vastaavalla tavalla, tarjoten samat metatiedot versiointiin liittyen (blob_hash, commit_hash). Sisällön versiointia Git versionhallintaa käyttäen kuvataan myöhemmin. Ohjelman tulee osata lähettää REST rajapinnan välityksellä metatietolistoja, jotka sisältävät yhteen commit operaatioon liittyvät metatiedot kerrallaan. Ohjelman tulee pitää kirjaa siitä, mihin commit operaatioon liittyvät metatiedot se on päivittänyt VisualREST palvelimelle. 6. Ohjelman tulee tasaisin väliajoin ilmoittaa online tilastaan REST rajapinnan välityksellä, jotta sen varastoiman sisällön essentiaa voitaisiin välittää. 7. Ohjelman tulee ennen sisällön essentian välittämistä ilmoittaa palvelinohjelmistolle lataamisen käynnistämisestä online viestin avulla. Samoin essentian lataamisen valmistuttua tuleen online viestin avulla ilmoittaa lataamisen valmistumisesta. Taulukko 3.1: Komento sisällön essentian lataamiseksi VisualREST palvelimelle. Komento: upload <tiedostopolku> <commit hash> Palvelin komentaa tietosäiliöohjelmaa lataamaan parametrina annetun tiedoston VisualREST palvelimelle. Parametri <tiedostopolku> sisältää tiedoston kokonaisen sijaintipolkun tietosäiliöohjelman hakemistoissa. Parametri <commit hash> määrittää ladattavan tiedoston version. Tämä yhdistelmä olisi teoriassa mahdollista korvata myös Blob hash arvolla, mutta käytettävä Grit rajapinta ei tue tiedostojen hakemista versionhallinnasta tämän tiedon avulla. Esimerkki: upload /harald.gif d8f7f710ee58a8590c271f d63112a14

36 3. Järjestelmän yleiskuvaus 30 Taulukko 3.2: Komento commit operaatioon liittyvien esikatselukuvien generoimiseksi ja välittämiseksi VisualREST palvelimelle. Komento: thumbs <commit hash> Palvelinohjelmisto komentaa tietosäiliöohjelmaa generoimaan esikatselukuvat niistä tiedostojen versioista, jotka kuuluvat parametrina anettuun committiin. Commit on Git versionhallintajärjestelmän tapa koota yhteen joukko tiedostojen versioita, ja tälle joukolle generoidaan Git:in termein ilmaistuna commit id. Toteutetun järjestelmän kohdalla käytetään kuitenkin termiä commit hash tai commit_hash, sillä commit_id on varattu sovelluskehyksen käyttötarkoituksiin. Esimerkki: thumbs 8b10da93353e0e27ef9bdb802f835c92ca Taulukko 3.3: Komento uusimman metatietolistan lähettämiseksi palvelimelle. Komento: list Vastaanottaessaan list komennon tulee tietosäiliöohjelman lähettää viimeisin metatietolista VisualREST palvelimelle. Tätä komentoa voidaan käyttää hyödyksi ongelmatilanteiden selvittämisessä. Taulukko 3.4: Viesti metatietolistan parsimisen onnistumisesta tai epäonnistumisesta. Viesti: parse [successful <commit hash> error] Tietosäiliöohjelman lähettäessä metatietolistaa VisualREST palvelimelle REST rajapinnan välityksellä, kuittaa palvelinohjelmisto metatietolistan parsinnan aloittamisen palauttamalla HTTP paluukoodin 202. Tällä koodilla tarkoitetaan, että operaatio on aloitettu, mutta sen lopputuloksesta ei voida vielä olla varmoja. Kun palvelinohjelmisto on saanut metatietolistan parsinnan suoritettua loppuun, lähettää se tietosäiliöohjelmalle viestin: parse successful <commit hash>, mikäli se on onnistuneesti saanut lisättyä lähetetyt metatiedot. Ongelmatilanteissa palvelinohjelmisto lähettää viestin: parse error, jolloin metatietojen lähettämistä voidaan yrittää uudelleen. Parametri commit hash pitää sisällään tiedon siitä, mitä tiedostoversioita metatietolista koskee. Esimerkki: parse successful 8b10da93353e0e27ef9bdb802f835c92ca423728

37 3. Järjestelmän yleiskuvaus Esimerkkitoteutuksen yleiskuvaus Tietosäiliöohjelman esimerkkitoteutus (kuva 3.5) käynnistetään hakemistossa, jonka sisältö halutaan tuoda osaksi VisualREST järjestelmän tarjoamaan pilvipalvelua. Käynnistettäessä tietosäiliöohjelmaa tässä hakemistossa ensimmäistä kertaa, pyydetään käyttäjää syöttämään käyttäjätunnus ja salasana, jotka käyttäjä on valinnut rekisteröityessään palveluun. Tämän lisäksi käyttääjää pyydetään valitsemaan laitetunnus (device name), joka yksilöi tietosäiliöohjelman tarkkaileman ympäristön. Tässä käytetään ilmaisua ympäristö, sillä yhden laitteen eri hakemistoissa on mahdollista suoritaa useaa tietosäiliöohjelmaa rinnakkain. Kuitenkin tarkoituksenmukaisempaa on suorittaa tietosäiliöohjelmaa sellaisen hakemistorakenteen juuressa, joka käytännössä sisältää kaiken laitteen tietosisällön. Esimerkiksi Unix järjestelmissä tällainen hakemisto voisi olla käyttäjän kotihakemisto. Se, minkä hakemiston sisällön käyttäjä haluaa tuoda osaksi pilvipalvelua, määrää luonnollisesti kuitenkin käyttäjä itse. Kuva 3.5: Valokuva esimerkkinä toteutetun tietosäiliöohjelman toiminnasta Nokia N900 matkapuhelimessa. Tietosäiliöohjelman rekisteröinnin jälkeen esimerkkitoteutus tutkii tasaisin väliajoin tiedostoissa tapahtuvia muutoksia. Mikäli tietosäiliöohjelma havaitsee uusia tie-

38 3. Järjestelmän yleiskuvaus 32 dostoja tarkkailtavassa hakemistopuussa, lisätään nämä tiedostot versionhallintaan. Tämän jälkeen tiedostojen metatiedot lähetetään versiotietoineen VisualREST palvelimelle. Tietosäiliöohjelman käyttäminen tapahtuu yksinkertaisen komentorivikäyttöliittymän avulla. Syöttämällä yksinkertaisia komentoja käyttäjä voi komentaa ohjelmaa esimerkiksi lähettämään uusimman metatietolistan VisualREST palvelimelle. Käyttäjän lisäksi myös palvelinohjelmisto voi käyttää tietosäiliöohjelmaa tämän komentorivikäyttöliittymän avulla lähettämällä komennot XMPP viestien avulla. Tarkoituksenmukaista onkin, ettei ihmiskäyttäjän tarvitse komentaa tietosäiliöohjelmaa käynnistämisen jälkeen, vaan tietosäiliöohjelma huolehtii toiminnastaan itsenäisesti, kommunikoiden palvelinohjelmiston kanssa. Lisäksi palvelinohjelmisto komentaa tietosäiliöohjelmaa XMPP rajapinnan välityksellä tarpeen niin vaatiessa. Kuvassa 3.5 on esitetty tosielämän tilanne siitä, miten tietosäiliöohjelman esimerkkitoteusta suoritetaan Nokian N900 älypuhelimella. Kuvasta voidaan nähdä, miten tietosäiliöohjelma on vastaanottanut VisualREST palvelimen lähettämän thumbs komennon ja lähettänyt tämän seurauksena esikatselukuvat VisualREST palvelimelle. Tämän jälkeen tietosäiliöohjelma on vastaanottanut VisualREST palvelimen lähettämän upload komennon ja aloittanut komennon parametreina annetun Kuva1.jpg tiedoston lataamisen VisualREST palvelimelle. 3.3 REST sisällönhallinnan näkökulmasta Aikaisemmin on jo tutustuttu REST suunnitteluperiaatteisiin, ja todettu että yleisin tapa toteuttaa REST rajapinta, on käyttää hyväksi URI osoitteita ja HTTP protokollan tarjoamia ominaisuuksia [27]. Seuraavaksi tutustutaan siihen, miten REST:in käsitteitä ja ominaisuuksia voidaan käyttää hyväksi sisällönhallintajärjestelmässä. Lisäksi käydään läpi VisualREST järjestelmän resurssit ja niiden jakautuminen hierarkkisiksi kokonaisuuksiksi. Hierarkkisten kokonaisuuksien avulla määritellään myös käsitettä konteksti. Sisällönhallinnan näkökulmasta REST suunnitteluperiaatteiden etuja ovat resurssilähtöinen näkökulma, sekä yhtenäisen rajapinnan hierarkkinen rakenne, joka on tyypillisesti seurausta URI osoitteiden johdonmukaisesta käytöstä (ominaisuus 2). REST suunnitteluperiaatteiden kuvauksen yhteydessä mainittiin, että resurssi voi käytännössä olla mikä tahansa asia, joka itsessään on niin tärkeä, että siihen tulee voida viitata. Sisällönhallintajärjestelmän kontekstissa onkin hyvin luonnollista ajatella, että hallittavat sisällöt tarvitsevat yksilöllisen osoitteen. Tämän osoitteen avulla voidaan yksittäiseen sisältöön viitata yksikäsitteisesti, ja näin ollen suorittaa CRUD operaatioita REST rajapinnan välityksellä. Sisällön versiointi kuitenkin osaltaan monimutkaistaa resurssin ja sisällön käsitteiden välistä suhdetta, sillä sisällön saatavuuden turvaamiseksi tulee olla selvää

39 3. Järjestelmän yleiskuvaus 33 Kuva 3.6: Resurssien hierarkkisuus. mihin sisällön versioon osoiteella viitataan. Jotta käyttäjät voisivat varmistua tästä, tulisi jokaisella sisällöstä tuotetulla versiolla olla oma yksilöllinen osoitteensa. Tämänkaltainen sisällön ja sisällöstä tuotetun version erottaminen omiksi resursseikseen saattaisi kuitenkin turhaan monimutkaistaa sisällön käsitettä ja näin ollen myös järjestelmän rajapintaa. Tästä johtuen VisualRESTin tapauksessa ei sisältöä ja siitä tuotettuja versiota ole haluttu erottaa kahdeksi erilliseksi resurssiksi, vaan puhuttaessa sisällöstä resurssina, voidaan sen aina käsittää tarkoittavan tiettyä sisällön versiota. Mikäli versiota ei ole erikseen määritelty, viittaa osoite aina sisällöstä tuotettuun viimeisimpään versioon. Muussa tapauksessa sisällön versio määritetään URI osoitteen kyselyosaan sijoitettavan version parametrin avulla. Kuvassa 3.6 on esitetty muita VisualREST järjestelmän resursseja, joita ovat käyttäjät, sekä näiden käyttäjä resurssien aliresursseiksi luodut käyttäjäryhmä ja laite resurssit. Käyttäjäryhmä resursseilla on aliresursseinaan ryhmänjäsen resursseja, jotka toisaalta voidaan ajatella myös toisina käyttäjä resursseina. Laite resursseilla puolestaan voi aliresursseinaan olla edellä mainittuja sisältö resursseja. Käyttäjäryhmälle sisältöön myönnetyt oikeudet ovat myös resursseja, sillä niitä on voitava lisätä ja poistaa helppokäyttöisen rajapinnan välityksellä. Sisällönhallintajärjestelmän ominaisuuden 5 mukaan sisältöä tulee voida kuvailla mielivaltaisen ja heterogeenisen metatiedon avulla, joten metatietojen voidaan ajatella olevan sisällön aliresursseja. Metatietoja voidaan perustellusti pitää omina resursseinaan, sillä VisualREST pohjautuu muiden sisällönhallintajärjestelmien tapaan hyvin suuressa määrin metatietojen käsittelemiseen. Mikäli sisältöä kuvai-

40 3. Järjestelmän yleiskuvaus 34 levalla metatiedolla on oma yksilöllinen osoite, voidaan tätä metatietoa käsitellä CRUD operaatioiden avulla. VisualREST järjestelmässä metatiedoilla tulee aina olla ennaltamääritelty tyyppi. Käyttäjille on haluttu tarjota helppokäyttöinen tapa näiden metatietotyyppien luomiseen, joten myös metatietotyypit ovat resursseja. Kuten aikaisemminkin on jo mainittu, järjestelmän resurssit muodostavat hierarkkisia kokonaisuuksia, joita on pyritty tuomaan esiin kuvassa 3.6. Kuvan vasen puolisko kuvaa sitä, miten resurssit voidaan nähdä käyttäjä-resurssin aliresursseina. Oikealla puoliskolla on annettu esitetty, miten näihin resurssien hierarkkiatasoihin voidaan yksilöllisen osoitteen avulla viitata. Osoitteista on kuitenkin jätetty pois asian ymmärtämisen kannalta epäoleellinen osuus. Hierarkkiatasojen voidaan myös ajatella määrittävän eräänlaisia konteksteja, jotka ikään kuin rajaavat sitä sisältöjen joukkoa, joihin osoitteella viitataan. Kontekstin käsite saa tärkeän merkityksen, kun sisältöä pyritään etsimään. Määrittelemällä konteksti mahdollisimman tarkasti ja tarkoituksenmukaisesti, voidaan haku kohdistaa vain olennaiseen sisältöön. Esimerksiksi mikäli ollaan etsimässä vain käyttäjän kalle jpeg muotoisia tiedostoja, voidaan haku suorittaa kahden erilaisen kontekstin kautta: /files?type=jpeg&user=kalle /user/kalle/files?type=jpeg Kumpikin tapa palauttaa samat hakutulokset. Kuitenkin ensin mainittua tapaa käytettäessä kontekstiin kuuluvat kaikki järjestelmään tuodut tiedostot ja tarkentavat hakuparametrit joudutaan tutkimaan kaikille järjestelmän tiedostoille. Jälkimmäistä tapaa käytettäessä kontekstina on käyttäjän kalle tiedostot, jolloin tarkentavat parametrit joudutaan tutkimaan vain kaikille yksittäisen käyttäjän tiedostoille, kontekstin rajatessa haun ulkopuolelle suurimman osan järjestelmän sisällöstä. Luonnollisesti hakuja on mahdollista optimoida palvelinohjelmiston puolella, jolloin yllä mainittu esimerkki saattaa menettää merkityksensä. Optimoinnissa on kuitenkin hyvin vaikeaa ottaa huomioon kaikkia erikoistapauksia, joita ainakin mielivaltainen ja heterogeeninen metatieto saattaa synnyttää.

41 3. Järjestelmän yleiskuvaus Palvelinohjelmiston REST rajapinnan kuvaus Aikaisemmin on jo perehdytty REST:in mukaisiin suunnittelukriteereihin, ja siihen miten näitä kriteereitä voidaan hyödyntää sisällönhallinnan näkökulmasta. Seuraavaksi tutustutaan järjestelmän REST rajapintaan. Yksittäisiin resursseihin viittaavat URI osoitteet on listattu omiksi kohdikseen, ja niiden kuvauksissa on selitetty, miten HTTP protokollan GET, PUT, POST ja DELETE metodien käyttäminen vaikuttaa viitattuun resurssiin. Osoitteista on jätetty pois HTTP protokollaa, palvelimen nimeä ja käytettävää porttia vastaava osa, sillä näillä tiedoilla ei rajapinnan kuvauksen kannalta ole merkitystä. Osoitteet on ryhmitelty kontekstin mukaan. REST suunnitteluperiaatteiden mukaan resurssien metatiedot tulisi noutaa HTTP protokollan HEAD metodia käyttäen [27, s. 98]. VisualREST järjestelmä kuitenkin keskittyy sisällönhallintajärjestelmien tapaan hyvin suuressa määrin sisällön metatietojen käsittelemiseen. Näin ollen järjestelmään kuuluvat resurssit ovat lähes poikkeuksetta sisällön metatietoa, eivätkä sisällön varsinaista essentiaa. Tästä syystä, ja osittain käytännön sovellusten toteuttamisen helpottamiseksi, järjestelmään tuodut metatiedot noudetaan HTTP protokollan GET metodia käyttäen. Tämän metodin käyttäminen helpottaa muun muassa web käyttöliittymän toteuttamista, sekä mahdollistaa metatietojen noutamisen joidenkin valmiiden sovellusohjelmien avustuksella. Päällimäisin syy siihen miksi HEAD metodia ei VisualREST järjestelmässä käytetä, on kuitenkin se ettei HEAD metodia käyttävään pyyntöön voida palauttaa lainkaan HTTP vastauksen runko-osaa (engl. body), vaan tiedot tulee välitää vastauksen otsakkeissa (engl. header) [13]. HTTP pyyntöjen palauttamat paluukoodit on kuvattu omassa alakohdassaan ja URI osoitteen kyselyosan avulla tarkentavien hakuriteerien määrittämistä on käsitelty alakohdassa Polkujen kuvausten yhteydessä mainitaan, mikäli operaation tekeminen vaatii autentikointia. REST rajapinnan käyttämää autentikointimenetelmää on kuvattu tarkemmin jäljempänä Konteksti: käyttäjätunnus Käyttäjä kontekstin näkyvyysalueelle kuuluvat käyttäjä resurssin lisäksi kaikki kyseisen resurssin alaisuuteen kuuluvat resurssit. Tämän kontekstin käyttäminen rajaa näin ollen näkyvyysalueen ulkopuolelle kaikki osoitteessa mainitsemattomat käyttäjäresurssit, samoin kuin niiden alaisuuteen kuuluvat aliresurssit. Taulukoissa on käyty läpi käyttäjä kontekstin alaisuuteen kuuluva osuus REST rajapinnasta.

42 3. Järjestelmän yleiskuvaus 36 Taulukko 3.5: Käyttäjä resurssi. /user/<käyttäjätunnus> PUT Lisää uuden käytäjän järjestelmään. Lisättäessä uutta käyttäjä tulee paremetrina antaa käyttäjän koko nimi (real_name), sekä salasana (password). Kun käyttäjä on luotu, palauttaa palvelin HTTP vastauksena paluukoodin, sekä luodun käyttäjä resurssin tiedot XML muodossa. Taulukko 3.6: Käyttäjän laitteet. /user/<käyttäjätunnus>/devices GET HTML Lista kaikista osoitteessa annetun käyttäjätunnuksen näkyvyysalueelle kuuluvista laitteista. Osoitteen perään on mahdollista liittää URI osoitteen kyselyosa, jonka avulla voidaan rajata tulosjoukkoa. GET Atom Tätä operaatiota voidaan käyttää yhdessä Atom syötteen kanssa, jolloin tiedot palautetaan XML muodossa. Taulukko 3.7: Käyttäjän tiedostot. /user/<käyttäjätunnus>/files GET HTML Osoite viittaa kaikkiin siinä mainittua käyttäjätunnusta vastaavan käyttäjäresurssin näkyvyysalueelle kuuluviin tiedostoresursseihin. HTML sivu joka sisältää listan kaikista käyttäjän tiedostoista. Tähän osoitteeseen on mahdollista liittää kyselyosa, jolla hakutulosten joukkoa voidaan pienentää suodattamalla hakutulosten ulkopuolelle sellaiset tiedostot, jotka eivät vastaa kysely-osassa annettuja parametreja. GET Atom Mikäli hakutulosten formaattina käytetään Atom syötettä, palautetaan tiedostolista XML muodossa.

43 3. Järjestelmän yleiskuvaus Konteksti: käyttäjätunnus ja ryhmätunnus Käyttämällä kontekstina käyttäjä ja käyttäjäryhmä resurssien yhdistelmää, rajataan näkyvyysalue koskemaan vain käyttäjäresurssin alaisuuteen kuuluvia käyttäjäryhmäresursseja, sekä niiden alaisuuteen kuuluvia resursseja. Ryhmäresurssin alaisuuteen kuuluu ryhmänjäsen resursseja. Taulukoissa on käyty läpi käyttäjätunnuksen ja ryhmätunnuksen kontekstin alaisuuteen kuuluva osuus REST rajapinnasta. Taulukko 3.8: Käyttäjäryhmä. /user/<käyttäjätunnus>/group/<ryhmätunnus> PUT Käyttäjälle luodaan osoitteessa annettua ryhmätunnusta vastaava käyttäjäryhmä. DELETE Poistaa käyttäjältä osoitteessa annettua ryhmätunnusta vastaavan käyttäjäryhmän. Poistettaessa käyttäjäryhmää poistuvat myös kaikki viitteet ryhmän ja siihen kuuluneiden käyttäjien väliltä. Käyttäjäryhmää käytetään tiedostojen oikeuksien hallitsemiseen. Taulukko 3.9: Käyttäjäryhmänjäsen. /user/<käyttäjätunnus>/group/<ryhmätunnus>/ member/<käyttäjätunnus> PUT Käyttäjät voivat lisätä toisia käyttäjiä omistamiinsa käyttäjäryhmiin. Tällöin osoitteen member kohdassa annettua käyttäjätunnusta vastaava käyttäjä lisätään osoitteessa mainittuun käyttäjäryhmään. Käyttäjän kuulumista käyttäjäryhmään kuvataan ryhmänjäsen resurssilla. DELETE Poistaa osoitteessa annettua käyttäjätunnusta vastaavan käyttäjän ryhmätunnusta vastaavasta käyttäjäryhmästä. Tällöin poistetaan käyttäjän kuulumista käyttäjäryhmään kuvaava ryhmänjäsen resurssi.

44 3. Järjestelmän yleiskuvaus Konteksti: käyttäjätunnus ja laitetunnus Käyttämällä kontekstina käyttäjä ja laite resurssien yhdistelmää, rajataan näkyvyysalue koskemaan vain käyttäjäresurssin alaisuuteen kuuluvia laiteresursseja, sekä laiteresurssin alaisuuteen kuuluvia resursseja. Taulukoissa on käyty läpi käyttäjätunnuksen ja laitetunnus kontekstin osuus REST rajapinnasta. Taulukko 3.10: Käyttäjän laite resurssi. Vastaa tietosäiliöohjelmaa. /user/<käyttäjätunnus>/device/<laitetunnus> PUT Käyttäjälle luodaan uusi osoitteessa mainittua laitetunnusta vastaava laite resurssi. Tämän operaation avulla käyttäjät rekisteröivät tietosäiliöohjelmat, ja laiteresurssin voidaankin ajatella vastaavan yksittäistä tietosäiliöohjelmaa. Parametrina annetaan laitteen tyypi (dev_type). Tämän operaation suorittaminen vaatii autentikointia. Taulukko 3.11: Laite resurssin sisältö. /user/<käyttäjätunnus>/device/<laitetunnus>/files GET HTML Palauttaa listan tiedostoista, jotka kuuluvat käyttäjätunnuksen ja laitetunnuksen näkyvyysalueelle. Kyseinen operaatio toimii samojen periaatteiden mukaan, kuin käyttäjätunnus kontekstin yhteydessä osoitteen viitatessa kaikkiin käyttäjän tiedostoihin, nyt vain rajaten hakutuloksia vain tietyn laitteen näkyvyysalueelle. Tiedostojen metatietojen hakeminen esittää käyttäjälle vain ne hakutulokset joihin heillä on käyttöoikeudet, joten autentikoinnin käyttäminen on näin ollen vapaaehtoista. Hakujen tuottamat tulokset ovat kuitenkin riippuvaisia käyttäjästä. GET Atom Palauttaa yllä kuvatut metatiedot Atom syötteen muodossa. POST Osoittessa mainitulle laitteelle lisätään uusia tiedostojen metatietoja, lähettäen commit operaatiota vastaava metatietolista. Tällöin HTTP pyynnölle annetaan contains niminen parametri, joka sisältää lisättävät metatiedot YAML muodossa [36]. Tästä metatietolistasta ja viestin muodosta on annettu esimerkki liitteessä A. Lisäksi parametrina tulee antaa lähetettävän tiedostolistan ja edellisen lähetetyn tiedostolistan uniikit tunnisteet (commit_hash, prev_commit_hash,), jotka tietosäiliöohjelman Git versionhallintaohjelmisto on laskenut niille. Optionaalinen parametri commit_location sisältää GPS koordinaatit, siltä ajanhetkeltä kun metatietoja tuottava tietosäiliöohjelma huomasi tiedostoissa tapahtuneet muutokset, ja talletti nämä muutokset versionhallintaan. Metatietojen lisääminen laitteelle vaatii autentikointia. PUT Toimii vastaavalla tavalla kuin yllä kuvattua POST metodia käytettäessä.

45 3. Järjestelmän yleiskuvaus 39 Taulukko 3.12: Laitteen online tila. /user/<käyttäjätunnus>/device/<laitetunnus>/online POST Tietosäiliöohjelma voidaan merkitä online tilaan. Online tilasta tulee ilmoittaa VisualREST palvelimelle kahden minuutin välein, ellei muita rajapinnan metodeja kutsuta sitä ennen. Jokainen metodi, joka käyttää käyttäjätunnus ja laitetunnus kontekstia, sekä vaatii autentikoinnin, päivittää samalla myös laitteen online statusta. Paramterina tälle operaatiolle voidaan antaa laitteen lokaatiotieto, tai tieto siitä onko metatietoja tuottava tietosäiliöohjelma lataamassa tiedostoa palvelimelle. Tiedostojen lataamisen palvelimelle on perehdytty tarkemmin tietosäiliöohjelman ja palvelimen välisen yhteistoiminnan kuvauksen yhteydessä. Esimerkki: status parametrin sisältö, kun ollaan aloittamassa sisällön essentian lataamista palvelimelle: status = "--- uploading_file: /kansio/kuva1.jpg device_location: latitude: 61.5 longitude: uploading_file_hash: ae087ff1a4dff391bfe286156a61fb1a1470a6e6

46 3. Järjestelmän yleiskuvaus Konteksti: käyttäjätunnus, laitetunnus ja tiedosto Käytettäessä kontekstina käyttäjä, laite ja tiedosto resursseja rajataan näkyvyysalue koskemaan vain niitä resursseja, jotka kuuluvat tiedostoresurssin alaisuuteen. Tiedostoresurssien alaisuuteen kuuluvat tiedostojen metatietojen lisäksi tiedostoon liittyvät käyttöoikeusresurssit, sekä tiedostoversioiden metatiedot. Taulukoissa on käyty läpi käyttäjätunnuksen, laitetunnuksen ja tiedoston kontekstin alaisuuteen kuuluva osuus REST rajapinnasta. Taulukko 3.13: Sisältö resurssi. /user/<käyttäjätunnus>/ device/<laitetunnus>/files/<tiedosto>?version=<versionumero> GET Sisällön essentian noutaminen VisualREST palvelimen kautta. Parametrina voidaan antaa halutun sisällön versionumero osoitteen kyselyosassa version parametrin avulla, jolloin VisualREST palvelinohjelmisto komentaa tietosäiliöohjelmaa lataamaan tämän tiedostoresurssin version sisällön. Mikäli versionumeroa ei anneta, komentaa VisualREST palvelin oletuksena tietosäiliöohjelmaa lataamaan tiedostoresurssin uusimman version sisällön. Järjestelmän toimintaperiaatteista johtuen tietosäiliöohjelman tehtävänä on ensin ladata sisällön essentia palvelimelle, josta essentia välitetään edelleen sitä pyytäneelle rajapinnan asiakkaalle. Tiedostojen sisällön hakeminen palvelimelta vaatii autentikoinnin mikäli tiedostoresurssin käyttöoikeusresursseissa tiedosto on määritetty yksityiseksi. PUT Sisällön essentian lataaminen VisualREST palvelimelle. Parametrissa upload on palvelimelle ladattavan sisällön essentia binäärimuodossa. Lisäksi parametrina tulee antaa blob_hash, joka yksilöi sisällön. Ennen lataamisen aloittamista tietosäiliöohjelman tulee ilmoittaa edellä kuvattua online operaatiota käyttäen lataamisen aloittamisesta ja päätyttyä lataamisen päättymisestä muuttamala tilaansa. Tätä operaatiota käytetään lisäksi esikatselukuvakkeiden lataamiseen palvelimelle, jolloin ylimääräisenä parametri arvo parina tulee antaa thumbnail="true". Tiedostojen essentian ja esikatselukuvakkeiden lataaminen palvelimelle vaatii autentikoinnin. Taulukko 3.14: Sisällön metatiedot versioittain. /user/<käyttäjätunnus>/device/<laitetunnus>/fileversions/<tiedosto> GET HTML Lista, joka sisältätää kaikki osoitteessa mainitun sisällön versioiden metatiedot HTML muodossa. Vaatii autentikointia mikäli sisällön käyttöoikeudet on asetettu yksityisiksi. GET Atom Metatiedot voidaan palauttaa myös Atom syötteen muodossa.

47 3. Järjestelmän yleiskuvaus 41 Taulukko 3.15: Sisällön ryhmäoikeudet /user/<käyttäjätunnus>/device/<laitetunnus>/filerights/<tiedosto> POST Yksittäisen tiedoston käyttäjäryhmäoikeuksien muokkaminen. Sisältö voi olla joko julkista (public) tai siihen voi olla oikeudet vain tietyillä käyttäjäryhmillä. Muutettaessa sisältö julkiseksi tehdään HTTP pyyntö antaen parametriksi arvopari: public=>"true". Tiedoston käyttöoikeudet voidaan rajata vain halutuille käyttäjäryhmille antamalla parametrina arvopareja: group:<ryhmätunnus>=><arvo>. Parametrin avainosa muodostuu siis merkkijonosta group: ja siihen liitettävästä ryhmän tunnuksesta. Arvoksi voidaan antaa joko 0, mikäli halutaan evätä annetulta ryhmältä pääsy kyseiseen tiedostoresurssiin, tai 1 mikäli pääsy halutaan sallia. Ryhmäoikeuksien asettaminen vaatii autentikointia Muut kontekstit ja resurssit Tässä kohdassa selitetään muut REST rajapinnan osoitteet, jotka eivät suoraan liity edellä mainittuihin muihin konteksteihin. Mikäli kontekstia ei ole määritelty, viitataan osoitteella koko järjestelmän näkyvyysalueelle kuuluviin resursseihin. Taulukossa 3.16 esitelty osoite käyttää kontekstina kaikkea VisualREST järjestelmään tuotua sisältöä. Taulukossa 3.17 esitellyn osoitteen tapauksessa kontekstina toimii käyttäjien järjestelmään lisäämät metatietotyypit. Taulukossa 3.18 kuvaillaan osoite jolla viitataan yksittäiseen metatietotyyppi resurssiin. Taulukko 3.16: Järjestelmän tiedostot konteksti. /files GET HTML GET Atom Käytettäessä polkua files, ilman käyttäjän tai käyttäjän ja laitteen avulla määriteltyä tarkempaa kontekstia, viitataan koko järjestelmän kaikkiin tiedostoihin. Koska koko järjestelmän käyttäminen kontekstina on haluttu tehokkuussyistä estää, tulee tätä kontekstia käytettäessä hakua rajata mahdollisimman tarkasti kyselyosan avulla. Kyselyosaan liittyvää toiminnallisuutta kuvaillaan kohdassa Autentikoinnin käyttäminen on vapaaehtoista, mutta haun tulokset ovat riippuvaisia haun suorittavasta käyttäjästä. Kyselyn tulokset voidaan palauttaa myös Atom syötteen muodossa. Taulukko 3.17: Metatietottyypit konteksti. /metadatatypes GET HTML Lista käyttäjien luomista metatietotyypeistä HTML muodossa. GET Atom Lista voidaan pyytää myös Atom syötteenä.

48 3. Järjestelmän yleiskuvaus 42 Taulukko 3.18: Metatietotyyppi resurssi. /metadatatype/<metatietotyyppi> PUT Luotavan metatietotyypin nimi annetaan URI osoitteen kohdassa <metatietotyyppi>. Lisäksi value_type parametrin avulla voidaan määrittää onko kyseessä numeerinen tyyppi float, merkkijono string vai aikaleima date. Mikäli tätä parametria ei anneta, käytetään oletuksena merkkijonoa. DELETE Metatietotyypin poistaminen. Poistettaessa tyyppi, poistetaan myös siihen liittyvät arvot sisällöiltä. POST Lisäksi metatietotyypin uudelleen nimeäminen. Pyynnön mukana tulee antaa uusi nimi metatietotyypille parametrissa new_name HTTP paluukoodit Palvelinohjelmiston REST rajapinnalle on ominaista se, että rajapinnan kutsuja saa aina HTTP vastaus, mikäli pyyntö menee perille. HTTP vastaus sisältää paluukoodin (HTTP response code), sekä useimmissa tapauksissa myös viestin, joka talletetaan HTTP vastauksen body osaan. VisualREST järjestelmän vastaukset sisältävät viestin tyypillisesti vain virhetilanteiden sattuessa. Viesteillä pyritään antamaan vihjeitä rajapinnan käyttäjälle mahdollisen virheen selvittämiseksi. Paluukoodit tarjoavat tehokkaan tavan pyynnön onnistumisen tutkimiseksi, sillä vastauksesta tarvitsee lukea vain kolme ensimmäistä tavua [27, s. 376]. Alla on selvitetty järjestelmän käyttämät HTTP paluukoodit, sekä annettu esimerkkejä siitä, mikälaisissa tilanteissa koodeja tyypillisesti käytetään. 200 OK Tyypillinen vastaus käytettäessä HTML käyttöliittymää. Yleensä vastaus ei sinänsä sisällä varsinaista viestiä, vaan body osa sisältää HTML sivun. 201 Created Luotaessa uutta resurssia käyttäen HTTP pyynnön PUT tai POST metodia, saadaan vastaukseksi paluukoodi 201, mikäli operaatio onnistuu. Tyypillisesti viestiosuus jätetään tyhjäksi, tai sen sisältö on merkityksetön. 202 Accepted HTTP pyyntö on onnistuneesti hyväksytty ja sen parametreissa annettuja tietoja on aloitettu käsittelemään. Mikäli parametrina saatujen tietojen käsittelyssä ilmenee kuitenkin virheitä, operaatio keskeytyy, eikä tämän jälkeen anneta takuita siitä,

49 3. Järjestelmän yleiskuvaus 43 mitkä tiedot järjestelmässä jäävät voimaan. Tyypillisesti järjestelmän toteuttamisessa on kuitenkin pyritty noudattamaan tietokantojen transaktio käytännöstä tuttua toimintamallia, jonka mukaan kaikki uudet muutokset järjestelmässä perutaan, mikäli kesken tietojen käsittelyn syntyy virhetilanteita. VisualREST järjestelmä pyrkii lisäksi tiedottamaan XMPP viestein sitä tietosäiliöohjelmaa, jonka resursseja ongelma koskee. Metatietolistoja parsittaessa, tietosäiliöohjelmalle lähetetään aina XMPP viesti, joka kertoo operaation onnistumisesta tai virhetilanteesta. 401 Unauthorized Pyynnön suorittaminen vaatii asiakkaan autentikointia, mutta tätä ei ole suoritettu. Tyypillisesti asiakas ei ole asettanut pyyntöön tarvittavia parametreja autentikoinnin suorittamiseksi. 403 Forbidden Pyynnön suorittaminen vaatii asiakkaan autentikointia, eikä asiakkaalla ole valtuuksia suorittaa operaatiota. Kyseinen paluukoodi kuitenkin viestii siitä, että osoitteen viittaama resurssi on olemassa. 404 Not Found Mikäli osoitteen viittaamaa resurssia ei löydy järjestelmästä, palautetaan virhekoodi 404. Koodia käytetään myös silloin, kun osoitteessa annettu varsinainen resurssi löytyy, mutta sen olemassaoloa ei haluta paljastaa. 409 Conflict Mikäli rajapinnan käyttäjän toimet aiheuttaisivat konfliktin jo olemassaolevan resurssin kanssa, ilmoitetaan tästä paluukoodin avulla. Tyypillisesti tällainen virhetilanne syntyy silloin, kun yritetään luoda resurssia varatun yksilöllisen tunnisteen avulla, eikä resurssia voida ylikirjoittaa. 412 Precondition Failed Mikäli jotkin asiakkaalle asetetut esiehdot eivät täyttyneet palautetaan virhekoodi Request Entity Too Large Tätä paluukoodia käytetään, kun VisualREST palvelimelta on yritetty noutaa sisällön essentiaa jota ei vielä ole palvelimen välimuistissa, ja jonka koko on suurempi kuin 10 megatavua.

50 3. Järjestelmän yleiskuvaus URI osoitteiden kyselyosa URI osoitetta on mahdollista laajentaa osoitteen perään liitettävän kyselyosan avulla lisäämällä osoitteen loppuun?-merkki. Tätä merkkiä seuraa yhtäsuuruusmerkillä (=-merkki) erotettuja avain arvo pareja, jotka erotellaan toisistaan &-merkkiä käyttäen. [6, s. 23] Palvelinohjelmiston REST rajapinnan tapauksessa kyselyosaa käytetään sisältöön kohdistuvien hakuoperaatioiden yhteydessä tarkentavien parametrien liittämiseksi URI osoitteeseen. Tämänhetkisessä REST rajapinnassa, on kuitenkin eräs erikoistapaus kyselyosan käytössä: kun kontekstina toimii käyttäjätunnuksen, laitetunnuksen ja tiedoston yhdistelmä, kyselyosan avulla määritettävää version parametria käytetään viittaamaan tiettyyn sisällön versioon. Esimerkiksi seuraava polku, johon on lisätty kyselyosa: /user/testuser/device/n900/files/kuva18.jpg?version=0 viittaa sisällön Kuva18.jpg ensimmäiseen versioon. Tyypillisesti kyselyosaa kuitenkin käytetään, kun hakuoperaatioita kohdistetaan yllä mainittua laajempaan kontekstiin, ja mukaan halutaan liittää tarkentavia parametreja rajaamaan haun tuloksia. Kyselyosassa parametrina voidaan käyttää käyttäjien lisäämiä metatietotyyppejä, joita järjestelmässä voi olla hyvin suuri joukko. Muodoltaan metatietotyypit voivat olla aikaleimoja, numeerisia arvoja(float) tai mielivaltaisia merkkijonoja (string). Käyttäjille on haluttu antaa vapaat kädet omien metatietotyyppien lisäämiseen, ja sisällön kuvailemiseen tämän mielivaltaisen metatiedon perusteella. Tämä ominaisuus myös täyttää sisällönhallintajärjestelmän ominaisuuden 5. Metatietojen avulla voidaan myös määrittää arvoalueita, sillä järjestelmä tarjoaa tavan käyttää numeeristen arvojen ja aikaleimojen kanssa yksinkertaisia vertailuoperaattoreita pienempi kuin (<-merkki) ja suurempi kuin (>-merkki). Käytettäessä vertailuoperaattoreita lisätään haluttu operaattori arvon perään. Esimerkiksi seuraava polku ja kyselyosa: /user/testuser/files/?duration=60< suorittaa haun käyttäjän testuser tiedostoihin, ja ottaa hakutuloksiin mukaan vain sellaisen sisällön, jolle on lisätty metatieto duration, ja jonka arvo on pienempi kuin 60. Lisäksi merkkijonojen kanssa voidaan käyttää hyväksi jokerimerkkiä (*-merkki), joka voidaan liittää joko merkkijonon alkuun, loppuun tai sekä alkuun että loppuun. Tällöin jokerimerkkiä vastaavalla paikalla hakutermissä voidaan ajatella olevan mikä tahansa merkkijono. Yllä mainitun kaltainen haku saattaa kuitenkin rajata hakutulosten ulkopuolelle myös sellaista sisältöä, jotka saattaisi periaatteessa hakuehdot täyttää, mutta jolle

51 3. Järjestelmän yleiskuvaus 45 metatietoja ei kuitenkaan ole vielä lisätty. Ongelma on seurausta siitä, että sisällölle on mahdollista lisätä metatietoja heterogeenisesti, eikä kaikella sisällöllä näin ollen ole samoja metatietoja. Heterogeenisestä metatiedosta johtuvia ongelmia voidaan yrittää kiertää niin kutsutun harvan (engl. sparse) metatiedon käsitteen avulla. Tällöin hakutuloksiin otetaan mukaan kaikki sellainen sisältö, jolle metatieto on lisätty ja jonka arvoa vastaa haussa annettua arvoa, sekä myös kaikki sellainen sisältö jolle metatietoa ei ole lisätty. Tällöin hakutuloksiin saattaa kuitenkin tulla mukaan paljon epäolennaista sisältöä, ellei hakutulosten joukkoa onnistuta rajaamaan riittävästi muiden tarkentavien hakuparametrien avulla. VisualREST tukee sisällön etsimistä myös harvan metatiedon perusteella, vaikkakin tämän tavan käyttäminen saattaakin suuresta metatiedon määrästä ja heterogeenisestä luonteesta johtuen olla tehotonta. Käytettäessä harvaa metatietoa sisällön etsimiseen, tulee kyselyosan parametrina antaa avain arvopari: sparse=true. Aikaisemmin on myös mainittu, että kontekstin määrittäminen mahdollisimman tarkasti tehostaa hakuoperaatiota, sillä konteksti rajaa hakualueen ulkopuolelle suuren joukon epäolennaista sisältöä, joille kyselyosan avulla annettuja tarkentavia hakukriteereitä ei tarvitse erikseen tutkia. Nyrkkisääntönä voidaan ajatella, että aina mahdollimman pitkää URI osoitteen polku osuutta käytettäessä taataan mahdollisimman tehokas haku.

52 46 4. ARKKITEHTUURI JA TOTEUTUS Tässä luvussa keskitytään kuvailemaan VisualREST järjestelmän arkkitehtuuria ja toteutusta. Tarkastelun kohteena ovat erityisesti palvelinohjelmiston arkkitehtuuri, käytetyt toteutusteknologiat, sekä järjestelmän rakenne. Lisäksi kuvaillaan esimerkkinä toteutetun tietosäiliöohjelman rakennetta ja toimintaperiaatteita, sekä tietosäiliöohjelman ja VisualREST palvelinohjelmiston yhteistoimintaa. VisualREST palvelimen arkkitehtuuri on yhdistetty osaksi tätä lukua, sillä toteutusmenetelmien on huomattu vaikuttavan osaltaan järjestelmän arkkitehtuuriin. 4.1 VisualREST palvelimen arkkitehtuuri Tässä kohdassa kuvaillaan VisualREST palvelimen arkkitehtuuria ja toteutusta. Palvelimen toteuttamisessa käytettävät teknologiat vaikuttavat jossain määrin sen arkkitehtuuriin, joten tässä kohdassa tutustutaan myös näiden teknologioiden toimintaan Toteutusteknologiana Ruby on Rails VisualREST palvelinohjelmisto on toteutettu Ruby on Rails sovelluskehystä [28] käyttäen ja näin ollen noudattaa arkkitehtuuriltaan MVC arkkitehtuurin mukaisia periaatteita. Kyseinen arkkitehtuuri on alunperin suunniteltu työpöytäsovelluksille, mutta se on vähitellen yleistynyt myös yhdeksi käytetyimmistä web sovelluksien arkkitehtuurityyleistä. MVC arkkitehtuurissa mallit (model), näkymät (view) ja ohjaimet (controller) on eriytetty omiksi komponenteikseen. Eriyttämisen seurauksena modulien välinen tehtävänjako ja vastuualueet selkiytyvät. [35, s. 12] [18, s. 386] Mallien tehtävänä on huolehtia tietosisällön tallettamisesta, ja tarjota metodit tämän tietosisällön käsittelemiseen. Mallit koostuvat vaihtelevista joukoista tietoa, jotka moudostavat loogisia kokonaisuuksia ja kuvaavat nämä tiedot helposti ymmärrettäviksi käsitteiksi. Business logiikka kuuluu usein myös osaksi mallia, jolloin malli huolehtii logiikan asettamien rajotteiden mukaisesta toiminnasta. [35, s. 11] Näkymät tarjoavat käyttäjille web käyttöliittymän mallien tietojen tarkastelemiseen ja käsittelemiseen. Toisaalta näkymät saattavat myös huolehtivat tietojen esittämisestä muille sovelluksille helppokäyttöisessä muodossa. VisualREST järjestelmässä tiedot asiakasohjelmille esitetään Atom syötteen avulla, jolloin metatiedoista

53 4. Arkkitehtuuri ja toteutus 47 jäsennetään XML dokumentti. Esimerkki tällaisesta dokumentista löytyy liitteestä B. Näkymät eivät aina suoraan kuvaa tietyn mallin tietosisältöä, vaan näkymien sisältö saattaa olla myös koostettu useiden mallien tietosisällöistä. Toisaalta samaan malliin voidaan tarjota useita erilaisia näkymiä eri käyttötarkoitusten mukaan. Kuva 4.1: MVC arkkitehtuuri Ruby on Rails web sovelluksissa [35, s. 69]. Thomas et al. kirjoittavat, että ohjainten tehtävänä on orkestroida sovellusta. Tällä tarkoitetaan sitä, että ohjaimet vastaanottavat tapahtumia (engl. event 1 ) ulkopuolisista lähteistä, vuorovaikuttavat tämän jälkeen mallien kanssa ja näyttävät lopuksi sopivan näkymän käyttäjälle. Näin ollen ohjaimet ovat hyvin keskeisessä roolissa MVC arkkitehtuurissa kontrolloidessaan sovelluksen toimintaa. Ohjainten logiikka päättää mitä tehdään, mallien logiikka puolestaan huolehtii siitä miten jokin toimenpide tehdään. Tästä tehtävienjaosta johtuen suurin osa sovelluksen toimintalogiikkaa sijaitsee ohjaimissa, sillä tyypillisesti yksittäisen toimenpiteen suorittamista haasteellisempaa on päätellä milloin toimenpide tulee suorittaa. [35, s. 69] Kuvassa 4.1 on vaiheittain esitetty miten tapahtuman kulku tyypillisesti etenee Ruby on Rails sovelluskehyksen mukaisessa arkkitehtuurissa. Kohdassa 1 asiakasohjelma, esimerkiksi web selain, lähettää HTTP pyynnön, jonka web palvelin vastaanottaa. Kohdassa 2 URI osoitteen rakenteesta ja tiedoista, sekä käytetystä metodista päättellen web palvelin reitittää pyynnön oikealle ohjain komponentille ja sen metodille. Metodin tehtävänä on käsitellä vastaanotettu pyyntö. Ruby on Rails sovelluksissa ohjain komponentit koostuvat metodeista, joista käytetään nimitystä action. Kuvassa on esimerkin vuoksi käytetty QueryController ohjainta. Kohdassa 3 ohjain vuorovaikuttaa mallien kanssa tehden pyyntöä vastaavat muutokset malleihin tai hakien mallien ylläpitämiä tietoja. Kohdassa 4 ohjain luo näkymän, joka sisältää malleista koostettua tietoa, tai vastaavasti viestin operaation vaikutuksista. VisualREST järjestelmässä näkymä voi olla muodoltaan joko 1 Alunperin MVC arkkitehtuuri on suunniteltu GUI sovelluksille (graphical user interface), joissa hyödynnetään tapahtumia (engl. event).

54 4. Arkkitehtuuri ja toteutus 48 HTML sivu tai Atom syöte. Kohdassa 5 näkymä generoi ohjaimen ja mallien tuottamat tiedot järjestelmää käyttävälle sovellukselle sopivassa muodossa. VisualREST järjestelmässä näkymä voi olla muodoltaan joko HTML sivu tai Atom syöte. Todettakoon myös, että useissa REST rajapinnan käyttötapuksissa voidaan näkymän generointi jättää ohjaimen vastuulle, sillä REST rajapintaa käytettäessä tärkeimmäksi osaksi tietosäiliöohjelman saamaa vastausta voidaan katsoa HTTP paluukoodi. Paluukoodin lisäksi vastaus voi sisältää myös joko resurssin representaation, tai lyhyen tekstimuotoisen virheilmoituksen, jota sovellusohjelmoijat voivat käyttää hyödykseen Fyysinen näkymä Kuvassa 4.2 on kuvattu VisualREST palvelimen fyysinen näkymä. Palvelin koostuu kolmesta erillisestä ohjelmistosta, joista kaikki voidaan myös tarpeen niin vaatiessa sijoittaa fyysisesti erillisille tietokoneille. Kuva 4.2: Palvelinohjelmiston fyysinen näkymä. Web sovellusten suorittaminen vaatii tyypillisesti web palvelinohjelmistojen käyttämistä. Ruby on Rails sovelluksia voidaan suorittaa esimerkiksi Ruby ohjelmointikielen mukana tulevan WEBRick palvelinkirjaston [29] avulla. Tämä palvelinkirjasto on kuitenkin ominaisuuksiltaan vaatimaton, joten VisualREST palvelinohjelmiston suorittamiseen käytetään Apache HTTP Server palvelinohjelmistoa [4], sekä sen Phusion Passenger modulia [26]. Tämän yhdistelmän avulla saadaan aikaiseksi tehokas, vakaa ja turvallinen suoritusympäristö, jota myös monet kaupalliset web sovellukset käyttävät. Palvelinohjelmiston toiminta ei kuitenkaan ole sidottu edellä mainitun yhdistelmän käyttämiseen, ja VisualREST palvelinohjelmistoa voidaan

55 4. Arkkitehtuuri ja toteutus 49 näin ollen suorittaa myös muita web palvelimia käyttäen. Ruby on Rails sovellukset vaativat tyypillisesti erillisen tietokannan käyttämistä. Tietokantana tämänhetkisessä VisualREST palvelinohjelmiston toteutuksessa on käytetty MySQL relaatiotietokantaa [24], mutta myös tietokanta voidaan korvata muilla, vastaavat ominaisuudet hallitsevilla, Ruby on Railsin tukemilla SQL tietokannoilla. XMPP viestien välittämiseen käytetään tämänhetkisessä toteutuksessa ejabberd nimistä XMPP palvelinohjelmistoa [10]. Kyseinen ohjelmisto tarjoaa hyvin skaalautuvan ja vikasietoisen tavan XMPP viestien välittämiseen [30, s. 253]. Myös tämä palvelinohjelmisto voidaan korvata muilla XMPP palvelinohjelmistoilla Palvelinohjelmiston tietosisältö ja mallit Ruby on Rails web-sovelluskehys käyttää relaatioita mallien (model) tietojen talletamiseen. Ruby on Railsin nimeämiskäytännön mukaan jokaista järjestelmän mallia vastaa monikkomuotoon nimetty relaatiotaulu. Sovelluskehys tarjoaa automatisoidun ja helppokäyttöisen tavan näiden mallien tietojen käsittelemiseen ActiveRecord nimisen rajapinnan kautta. Tämä rajapinta osaa muun muassa hakea pää- ja vierasavainten avulla toisiinsa linkitettyjä malleja yksinkertaisten komentojen avulla. Kuva 4.3: Palvelinohjelman tietosisältö. Palvelinohjelman tietosisältö on esitetty UML notaation maukaisena luokkakaaviona kuvassa 4.3. Luokat vastaavat Ruby on Railsin malleja (model), mutta kuvas-

56 4. Arkkitehtuuri ja toteutus 50 ta on kuitenkin jätetty pois luokat jotka kuvaavat mallien välisiä monesta moneen suhteita. Kuvassa monesta moneen suhteet on merkitty UML notaation mukaisten lukumääräsuhteiden (operaattori * ) avulla. Seuraavaksi on kuvattu järjestelmän mallit, sekä selittety niiden funktio järjestelmässä. Kuvausten yhteydessä mainitaan lisäksi se, mitä järjestelmän resurssia malli vastaa. User malli kuvaa järjestelmän yksittäistä käyttäjää. Malliin on käyttäjän rekisteröitymisen yhteydessä talletettu käyttäjää koskevat tiedot: yksilöllinen, käyttäjän yksilöivä käyttäjätunnus (username), käyttäjän koko nimi (real_name), sekä salasana (password). Lisäksi malli sisältää pääavaimen id. Käyttäjä malli vastaa käyttäjä resurssia. Group malli kuvaa käyttäjäryhmää. Käyttäjäryhmän avulla voidaan nimensä mukaisesti ryhmitellä käyttäjiä (user) erilaisiin ryhmiin, kuten esimerkiksi ystäviin ja perheenjäseniin. Käyttäjäryhmien avulla voidaan sallia vain tiettyjen käyttäjäjoukkojen pääsy tiettyihin tiedostoihin (devfile), liittämällä käyttäjäryhmä assosiaatiotaulun avulla tiedostoon. Group malli sisältää nimi käsitteen (name), pääavaimen (id), sekä vierasavaimen ryhmän omistavaan käyttäjään (user_id). Group malli vastaa resurssia käyttäjäryhmä, ja siihen liitetyt käyttäjä mallit aliresursursseja ryhmänjäsen. Device malli kuvaa järjestelmään liittyvää yksittäistä laitetta, jonka omistaa yksittäinen käyttäjä. Tämä omistussuhde on toteutettu vierasavaimella käyttäjään (user_id). Muita vierasavaimia ovat commit_id ja latest_location_id. Näistä ensin mainittu viittaa laitteeseen viimeksi tehtyyn tiedostolistan päivitykseen (ks. Commit malli). Jälkimmäisenä mainittu viittaa laitteen viimeisimpään sijaintiin (ks. DeviceLocation). Laitteella on attribuutteina käyttäjän kontekstissa laitteen yksilöivä yksikäsitteinen laitetunnus (dev_name), tyyppi (dev_type), tieto siitä milloin laite on viimeksi ollut online tilassa (last_seen), sekä XMPP tilin käyttäjätunnus ja salasana (XMPPname, XMPPpassword). Pääavaimena laitteella on (id). Laite malli vastaa laite resurssia. DeviceLocation malli kuvaa tietyn laitteen (Device) sijaintia tietyllä ajan hetkellä. Malli sisältää attribuutit latitude ja longitude, sekä relaation luomisajankohdan. Pääavaimena tomii id, ja vierasavain device_id osoittaa siihen laitteeseen, johon lokaatio liittyy. Devfile malli kuvaa yksittäisen tiedoston yläkäsitettä. Yläkäsitteellä tarkoitetaan sitä, ettei pelkkä Devfile malli vielä itsessään kuvaa kokonaista tiedostoa, vaan niitä tietoja jotka ovat kaikille tiedoston versioille (ks. Blob) yhteisiä. Attribuutteina Devfile mallilla on nimi (name) ja polku (path), jotka yksilöivät tiedoston käyttäjän ja laitteen kontekstissa. Lisäksi atribuutteina ovat: tiedostolle talletettu kuvaus (description), tiedoston tyyppi (filetype), tieto siitä onko tiedosto privaatti (privatefile), tiedoston luomis- ja viimeisin muokkaamisajankohta (created_at,

57 4. Arkkitehtuuri ja toteutus 51 updated_at), sekä lokaation GPS koordinaatit (latitude, longitude). Pääavaimena toimii id, ja vierasavaimet osoittavat tiedoston omistavaan laitteeseen (device_id), sekä viimeisimmän tiedostoversion metatietoihin, jotka on talletettu Blob malliin (blob_id). Devfile malli ja Blob malli vastaavat sisältö resurssia vastaavalla tavalla, kuin kohdassa 3.3 on esitetty. Blob malli kuvaa tiedoston (Devfile) tietyn version metatietoja. Alkunsa tämä käsite on saanut järjestelmän metatietoja tuottavassa tietosäiliöohjelmassa käytettävän Git versionhallintaohjelmiston vaikutuksesta. Gitissä blob kuitenkin kuvaa tiedoston varsinaisen sisällön essentiaa, eikä tiedostoon liittyvää metatietoa. Jokaisella blobille on Gitissä laskettu oma hash tiivisteensä, joka lasketaan tiedoston sisällöstä ja tiedoston koosta. Palvelinohjelmassa Blob malli kuvaa alkuperäisen idean vastaisesti tiedoston tiettyyn versioon liittyvää metatietoa ja metatiedon muutoksia. Git versionhallinnan käyttämistä sisällön versiointiin tässä järjestelmässä kuvataan myöhemmin. Blobilla on attribuutteina luomis- ja muokkaamisajankohdat (created_at, updated_at), tiedostoversion koko (size), tieto siitä onko kyseinen versio ladattuna palvelimelle (uploaded), tai vastaavasti ollaako versiota parhaillaan lataamassa palvelimelle (upload_requested), esikatselukuvan koko nimi (thumbnail_name), tiedostoversion numero (version), tiedoston sisällöstä laskettu tiiviste (blob_hash), sekä lokaation GPS koordinaatit (latitude, longitude). Commit malli kokoaa yhteen tiedostosta luotujen versioiden metatiedot, eli Blob mallit. Blobin tapaan tämäkin käsite on saanut alkunsa metatietoja tuottavan tietosäiliöohjelman käyttämästä Git versionhallintaohjelmistosta. Commit käsitteen alkuperäinen tarkoitus Git versionhallinnassa on koota yhteen vain ne muutokset jotka on tehty edelliseen committiin nähden. VisualREST järjestelmässä committiin liitetään näiden uusien muutoksien lisäksi myös aikaisemmat Blob mallit metatietoihin tehtävien hakujen tehostamiseksi. Näin ollen myös commit käsite eroaa järjestelmässä hieman alkuperäisestä Git versiohallinnan commit käsitteestä. Attribuutteina commit mallilla on metatietojatuottavan tietosäiliöohjelman Git versionhallinnan laskema hash tiiviste, joka toimii yksilöllisenä tunnisteena commitille (commit_hash). Pääavaimena toimii id, sillä vaikka commit_hash arvoa voitaisiinkin yksilöllisyytentä puolesta käyttää pääavaimena, soveltuu järjestelmän automaattisesti generoima kokonaisluku paremmin Ruby on Rails sovelluskehyksen tapaan linkittää relaatioita toisiinsa. Vierasavain previous_commit_id viittaa nimensä mukaisesti edelliseen tietosäiliöohjelman tekemään committiin. Haarautettaessa Devfile ja Blob mallin yhdistelmän kuvaamasta tiedostoversiosta uusi erillinen haara omaksi Devfile ja Blob mallin yhdistelmäkseen, voidaan tiedostoversioon linkittää tiedoston alkuperä Branch mallin avulla. Branch malli sisältää vierasavaimet alkuperäiseen Blob malliin (parent_blob_id), sekä haarau-

58 4. Arkkitehtuuri ja toteutus 52 tettuun Blob malliin (child_blob_id). Metadatatype malli kuvaa yksittäistä käyttäjän tai tietosäiliöohjelman lisäämää metatietotyyppiä. Järjestelmään liitettyjen metatietotyyppien muoto voi olla joko numeerinen (float), merkkijono (string), tai aikaleima (date). Metatietotyypin muoto annetaan parametrina sitä luotaessa, mutta oletuksena käytetään merkkijonoa. Määrittämällä muodoksi numeerinen muoto tai aikaleima, voidaan hakujen yhteydessä käyttää hyväksi vertailuoperaattoreita. Merkkijonojen yhteydessä taas on mahdollista käyttää hyväksi niin kutsuttuja jokeri merkkejä. Attribuuttina mallissa on tyypin nimi (name), pääavain id, sekä metatietotyypin muoto (value_type). Vastaa resurssia metatietotyyppi. Metadata malli sisältää järjestelmän käyttäjien tai asiakasohjelmien lisäämien metatietotyyppien arvot. Arvot on talletettu merkkijono muotoon (value attribuutti), ja tarpeelliset muunnokset tehdään niille käytön yhteydessä määritetyn metatietotyypin (Metadatatype) mukaan. Metadata mallit voidaan lisätä, joko tiedostolle ja sen kaikille versioille (Devfile), tai ainoastaan yksittäiselle tiedoston versiolle (Blob). Malli sisältää pääavaimen id, sekä vierasavaimet tiedostoon (devfile_id) ja tiedoston yksittäiseen versioon (blob_id). Näistä jälkimmäisenä mainittu asetetaan arvoon NULL, mikäli metatiedon halutaan kuuluvan kaikille versioille. Vastaa resurssia metatieto. Fileupload malli kuvaa käynnissä olevia tiedostolatauksia. Tietosäiliöohjelman aloittaessa sisällön essentian lataamisen palvelimelle, päivittää se ensin tilaansa luomalla Fileupload objektin, ja asettamalla siihen aloitusajankohtaa vastaavan aikaleiman (begin_time). Näin palvelinohjelmisto pitää kirjaa käynnissä olevista latauksista, ja vältytään usealta samanaikaiselta saman essentian lataamiselta. Kun lataus on suoritettu loppuun, päivittää palvelinohjelmisto myös lopetusajankohdan (end_time) Fileupload malliin. Fileupload malli sisältää lisäksi tiedon siitä, onko lataus palvelimelle parhaillaan käynnissä (inprogress), sekä ladattavaan sisällön versioon viittaavan vierasavaimen (blob_id). Tietosäiliöohjelman tilapäivityksiä on kuvattiin tarkemmin REST rajapinnan kuvauksen yhteydessä Palvelinohjelmiston rakenne Kuvassa 4.4 on esitetty VisualREST järjestelmän komponenttirakenne, ja kuvattu näiden komponenttien välisiä rajapintoja. Kuvan VisualREST palvelinohjelmisto komponentissa on lisäksi esitetty palvelinohjelmiston tärkeimmät luokat, joiden funktioita kuvaillaan tarkemmin seuraavaksi. Kuvasta on jätetty pois palvelinohjelmiston tietosisältöä kuvaava osuus, sillä tietosisältöä käsiteltiin yllä. Tietosisällön malleja kuvassa edustaa ActiveRecord malli. ApplicationController ohjain toimii isä luokkana, josta muut palvelinohjelmiston ohjaimet periytetään. Ohjain sisältää kaikille kontrollereille yhteistä toimin-

59 4. Arkkitehtuuri ja toteutus 53 Kuva 4.4: Palvelinohjelmiston komponenttirakenne. nallisuutta, kuten autentikointiin liittyvät tarkastukset, sekä XMPP viestien lähettämisen. QueryController ohjain sisältää palvelinohjelmiston hakuihin liittyvän toiminnallisuuden. Muihin kontrollereihin verrattuna ohjain käyttää tietokantaa myös suoraan, SQL kyselyitä tehden. Tässä kohtaa ActiveRecord mallien käyttäminen on haluttu kiertää tehokkuus syistä. Lisäksi ActiveRecord ei sovellu käytettäväksi useasta taulusta koostuvien kyselyiden tekemiseen. UserController ohjain sisältää käyttäjä resursurssien käsittelemiseen liittyvän toiminnallisuuden. Ohjaimen avulla voidaan muun muassa lisätä uusia käyttäjiä. DevfileController ohjain sisältää sisältö resurssien käsittelemiseen liittyvän toiminnallisuuden. Tämän ohjaimen avulla huolehditaan sisällön essentian vastaanottamisesta, kun tietosäilöohjelma lataa essentiaa palvelimelle. Lisäksi ohjain myös huolehtii käyttöoikeuksien valvonnasta essentiaa välitettäessä, ja metatiedon liittämisestä sisältöön. DeviceController ohjaimen avulla käsitellään laite resursseja. Muun muassa tietosäiliöohjelmien lähettämien metatietolistojen tiedot päivitetään järjestelmän tietokantaan tämän ohjaimen avulla. Lisäksi kontrolleri käsittelee laitteiden tekemiin online ilmoituksiin liittyvää tilatietoa. Kuvan 4.4 XMPP-worker komponentti toteuttaa XMPP viestien lähettämiseen käytettävän erillisen prosessin. XMPP viestien lähetys on eritytetty omaksi prosessikseen, sillä viestejä lähetetään ajoittain suuriakin kappalemääriä, eikä viestien välittämisen ole haluttu hidastavan palvelinohjelmiston toimintaa. Lisäksi ilman erillistä prosessia viestien lähettäminen saattaisi ruuhkautua. Palvelinohjelmisto käyttää XMPP-worker komponentin sendxmppmessage metodia, joka asettaa viestit viestijonoon. Jonoa puretaan välittämällä viestit niiden

60 4. Arkkitehtuuri ja toteutus 54 saapumisjärjestyksessä, jolloin ensimmäisenä jonoon tullut viesti välitetään ensimmäisenä myös eteenpäin. Kuvasta 4.4 nähdään, miten XMPP-worker komponentti käyttää hyödykseen tietosäiliöohjelmien toteuttamaa XMPP rajapintaa, joka määriteltiin tarkemmin taulukoissa Tämän rajapinnan käyttämisen lisäksi XMPP-worker komponenttia voidaan käyttää XMPP viestien välittämiseen myös muille XMPP asiakasohjelmille. Näin ollen XMPP viestejä voitaisiin käyttää myös esimerkiksi erilaisten ilmoitusten (engl. notification) välittämiseen muille järjestelmille tai sovelluksille. Kuvasta on selkeyden vuoksi jätetty pois XMPP palvelinohjelmisto. 4.2 Tietosäiliöohjelman esimerkkitoteutus Esimerkkinä toteutetun tietosäilöohjelman toimintaa käsiteltiin yleisesti edellisessä luvussa. Tässä kohdassa perehdytään tietosäiliöohjelman rakenteeseen, toimintaperiaatteisiin, sekä toteutuksessa käytettyihin teknologioihin. Kuva 4.5: Tietosäiliöohjelman rakenne Rakenne ja toimintaperiaatteet Tietosäiliöohjelman rakenne on esitetty kuvassa 4.5. Rakenteeltaan tietosäiliöohjelma on varsin yksinkertainen, koostuen pääohjelman lisäksi vain muutamasta luokasta. Tyypillisesti luokkien toteutus keskittyy täyttämään joitain alakohdassa mainittuja tietosäiliöohjelman vaatimuksia. Pääohjelma itsessään tomii eräänlaisena kontrollirakenteena, joka käyttää hyväkseen luokkien liityntöjä ulkoisiin järjestelmiin. Seuraavaksi perehdytään tietosäiliöohjelman luokkiin. GitUsage luokka toteuttaa tiedostojen versioinnin käyttäen hyväkseen Git versionhallintajärjestelmää. Pääohjelma tiedustelee GitUsage luokalta tasaisin väliajoin tiedostoissa tapahtuneita muutoksia. Mikäli tiedostoissa on tapahtunut muutok-

61 4. Arkkitehtuuri ja toteutus 55 sia, pyytää pääohjelma muuttuneiden tiedostojen metatietolistan GitUsage luokalta, ja välittää tiedot edelleen VisualREST palvelimelle. GitUsage luokan vastuulla on siis ylläpitää versiotietoa, ja yhdessä pääohjelman kanssa tarkkailla tiedostoissa tapahtuvia muutoksia. Richardson ja Ruby [27, s ] listaavat kirjassaan REST suunnitteluperiaatteiden kannalta olennaiset vaatimukset hyvälle HTTP kirjastolle, sekä antavat suosituksensa siitä, mitä kirjastoa eri ohjelmointikielillä tulisi käyttää REST suunnitteluperiaatteiden mukaisia asiakasohjelmia toteutettaessa. HttpRequest luokan toteutuksessa on käytetty hyväksi Richardsonin ja Rubyn suosittelemaa net/http kirjastoa. Kirjasto tarjoaa tuen lähes kaikille REST suunnitteluperiaatteiden kannalta olennaisille HTTP protokollan ominaisuuksille. Huonona puolena kirjaston käytämisessä on kuitenkin hankalahko käytettävyys. Tästä syystä tietosäiliöohjelmaan on toteutettu HttpRequest luokka, joka käärii (engl. wrapping) HTTP pyyntöjen tekemisen helposti käytettäväksi rajapinnaksi. Luokan avulla voidaan käyttää useimpia HTTP protokollan metodeja, sekä asettaa pyyntöihin parametreja. [27, s ] Toinen HTTP pyntöjen tekemistä helpottamaan toteutettu luokka on nimeltään Multipart. Tämän luokan avulla voidaan tehdä HTTP protokollan pyyntöjä PUT metodia käyttäen, siten että sisältö lähetetään useammassa osassa. Tätä luokkaa käytetään välitettäessä tiedostojen sisältöä VisualREST palvelimelle, sillä tiedostot voivat olla kooltaan hyvinkin suuria. Luokka toteuttaa tietosäiliöohjelman vaatimuksen, jonka mukaan tietosäiliöohjelman tulee voida välittää tiedostojen sisältöä VisualREST palvelimelle. Tietosäiliöohjelma päivittää sijaintitietonsa lähettäessään online ilmoituksia tai metatietoja palvelimelle. Sijainnin määrittämiseen käytetään ulkopuolisia verkkopalveluita, jotka osaavat määrittää sijainnin IP osoitteen perusteella. Location luokka käärii näiden palveluiden käytön helposti käytettäväksi rajapinnaksi, eikä ohjelmoijan tarvitse erikseen parsia palveluista saatuja vastauksia jokaisen pyynnön yhteydessä Tietosäiliöohjelman ylläpitämät tiedostot Tietosäiliöohjelmalle luodaan reskisteröinnin yhteydessä käyttäjä kontekstissa laitteen yksilöivä ja yksikäsitteinen laitetunnus, sekä XMPP tunnus ja salasana. Nämä tiedot tietosäiliöohjelma tallettaa device_identity nimiseen tiedostoon. Ensimmäisen käynnistyksen yhteydessä tietosäliöohjelma luo Git ohjelmavaraston (engl. repository), johon sisällön essentia talletetaan versioittain. Tämä ohjelmavarasto on.git/ hakemisto, joka Unix järjestelmissä on tyypillisesti piilotettu. Tietosäiliöohjelma pitää kirjaa commit operaatioihin liittyvien metatietolistojen päivittämisestä VisualREST palvelimelle. Näitä tietoja ylläpidetään hajautustau-

62 4. Arkkitehtuuri ja toteutus 56 luissa, joissa avaimena toimii commit operaation yksilöivä hash tiiviste. Arvona on tieto siitä, onko operaatioon liittyvät metatiedot päivitetty palvelimelle, sekä laiteen lokaatio commit operaation toteutumisen hetkellä. Tämän tiedon avulla sisältöön voidaan liittää paikkatietoa. Tiedot talletetaan commits_metafile nimiseen tiedostoon YAML muodossa. 4.3 Versionhallintajärjestelmänä GIT Seuraavaksi tutustutaan Git versionhallintajärjestelmään yleisellä tasolla. Kyseistä järjestelmää on käytetty tässä työssä kuvatun sisällönhallintajärjestelmän versioinnin toteuttamiseen, ja sisällön essentian varastoimiseen. Git versionhallintaa ei kuitenkaan kuvata täydellisesti, vaan ainoastaan tässä työssä kuvattavan VisualREST järjestelmän kannalta oleellisilta osin. Git versionhallintatyökalu on kehitetty Linux ytimen versionhallintaan kehitystyön avuksi. Linux ytimen, kuten useiden muiden laajasti levinneiden avoimen lähdekoodin järjestelmien, kehittäminen tapahtuu pääasiassa erittäin hajautetusti, ja tämä seikka onkin otettu suuressa määrin huomioon Git versionhallintaa suunniteltaessa. Git saattaa käyttöliittymältään kuitenkin olla useille ihmisille hankalasti lähestyttävä, sillä tyypillisesti tätä työkalua käytetään komentoriviltä. Lisäksi Git on kehitetty erityisesti hajautettua ohjelmistokehitystä silmällä pitäen, mikä saattaa aiheutaa hämmennystä. Hajutetusta toimintaperiaatteesta johtuen Git poikkeaa ideologialtaan ja toimintaperiaatteiltaan muista tyypillisistä versionhallintaohjelmistoista, kuten esimerkiksi Subversionista. [15] Git versionhallinnan toimintaperiaatteiden mukaan jokaisella käyttäjällä on täydellinen kopio ohjelmavarastosta (engl. repository). Tämän seikan ansiosta käyttäjät pääsevät nopeasti, sekä myös ilman verkkoyhteyttä käsiksi ohjelmavaraston versiohistoriaan. Esimerkiksi Subversioniin verrattuna tämä tarkoittaa sitä, että käyttäjien tulee niin sanotusti työntää (engl. push) tekemänsä muutokset muiden käyttäjien ohjelmavarastoihin, sekä noutaa (engl. fetch) muiden käyttäjien ohjelmavarastoihinsa tekemät muutoset itselleen. Subversionissa muutosten välittäminen ja noutaminen suoritetaan yhden keskitetyn ohjelmavaraston kautta, mutta Git versionhallinnassa tämankaltaista yhtä keskitettyä ohjelmavarastoa ei välttämättä tarvita. Toinen hyvin olennainen seikka, joka Gitissä eroaa muista tyypillisistä versionhallintajärjestelmistä on se, että Git ei muiden versionhallintajärjestelmien tapaan talleta eroja committien välillä, vaan sen sijaan Git tallettaa aina eräänlaisen tilannekatsauksen siitä, millaisia projektiin kuuluvat tiedostot commitin tekemisen hetkellä ovat. [15, 16] Kuvassa 4.6 on esimerkinomaisesti hahmoteltu sitä, millaiselta commit saattaa rakenteeltaan näyttää. Git versionhallinnassa commit objekti sisältää yksilöllisen commitin SHA tunnisteen, kuvauksen, sekä linkin tree objektiin. Tree objekti esit-

63 4. Arkkitehtuuri ja toteutus 57 Kuva 4.6: Esimerkki Git versionhallinnan commit operaation sisällöstä [16, s. 14]. tää hakemiston tai alihakemiston sisältöä. Näin ollen se voi sisältää linkin toisiin tree objekteihin, tai vastaavasti blob objekteihin. Blob objekti varastoi tiedoston sisällön, mutta on tärkeää huomata, että se ei lainkaan ole sidottu itse tiedostoon, tiedoston nimeen, niin kuin ei myöskään tree objektiin tai mihinkään muuhunkaan. Näin ollen kahden sisällöltään täysin identtisen tiedoston sisältö talletetaan vain yhteen kertaan, yhteen ainoaan blob objektiin. Blob objektin yksilöllinen SHA tunniste lasketaan pääasiassa objektin ylläpitämästä tiedoston sisällöstä, joten näin ollen pelkkiä tunnisteita vertaamalla voidaan varmistua kahden blob objektin identtisyydestä. Myös tree objektilla on yksilöllinen SHA tunniste, joka on rekursiivisesti täysin riippuvainen tree objektin kuvaaman hakemiston ja aliahakeistojen sisällöstä. Näin ollen myös kahden tree objektin vertaileminen on tehokasta. Muut objektien sisältämät tiedot on nähtävissä kuvassa 4.6. Kuvan vasemmassa alakulmassa on kuvattu se hakemistorakenne, johon commit operaatio on kohdistunut. [16, s. 9 14] Versioinnin toteuttaminen GIT:n avulla Järjestelmän toimintafilosofiasta johtuen sisällön essentia pyritään säilyttämään mahdollisuuksien mukaan sitä tuottavassa laitteessa. Tästä johtuen sisällön essentian

64 4. Arkkitehtuuri ja toteutus 58 säilyttämiseen ja versiointiin käytettävän Git versionhallintatyökalun tulee toimia samassa fyysisessä ympäristössä sitä käyttävän tietosäiliöohjelman kanssa. Havaitessaan muutoksia sisällössä ja siirtäessään muuttuneiden sisältöjen metatietoja palvelimelle, tietosäiliöohjelma lähettää palvelimelle aina kaikki yksittäiseen committiin kuuluvat initiaalimetatiedot. Näiden tietojen avulla palvelinohjelmisto luo sisältöä ja sen versioita vastaavat mallit ja tallettaa ne tietokantaan. Vaikka palvelinohjelmiston tietosisältö ei täydellisesti vastaakaan Git versionhallinnan tietosisältöä, on palvelinohjelmiston tietosisältö kuitenkin jossain määrin saanut vaikutteita Git:n tietosisällöstä. Palvelinohjelmisto ei kuitenkaan esimerkiksi sisällä lainkaan tree objektin käsitettä. Sen sijaan tiedoston kokonainen hakemistopolku on talletettu devfile objektiin, joka toimii eräänlaisena yläkäsitteenä, yhdistäen kaikki tiedostosta tuotetut versiot. Taulukko 4.1: Järjestelmän versiointiin liittyvät tietosisällön käsitteet verrattean Git järjestelmän käsitteisiin. commit Käsite Palvelinohjelmisto Git tree - Kuvaa hakemiston tai alihakemiston sisällön. Sisältää osoittimia blob objekteihin tai toisiin tree objekteihin. blob Kuvaa sisällön versiokohtaiset ini- Sisältää tiedoston essentian. tiaalimetatiedot. Kokoaa yhteen joukon tiettyyn committiin liittyviä metatietoja. Sisältää osoittimen sitä hakemistoa kuvaavaan tree objektiin, jonka sisältö tuodaan versionhallintaan. Eroavaisuudet tietosisällössä johtuvat jossain määrin siitä, että palvelinohjelmistossa ja Git versionhallinnassa malli objekteja käytetään erilaisiin tarkoituksiin. Palvelinohjelmisto keskittyy metatietojen ylläpitämiseen, kun taas tietosäiliöohjelman ylläpitämää Git versionhallintaa käytetään sisällön essentian varastoimiseen. Näin ollen palvelinohjelmiston blob objekti sisältää versiokohtaiset initiaalimetatiedot, kun taas Git versionhallinnassa blob objekti sisältää lähes yksinomaan tiedoston essentian. Myös commit objektin käsite poikkeaa palvelinohjelmiston puolella Git:n vastaavasta. Palvelinohjelmisto käyttää commit objektia nivoakseen yhteen kaikki ne blob objektit, jotka yksittäiseen committiin kuuluvat. VisualREST järjestelmän ja Git versionhallinnan käsitteiden välisiä eroja on pyritty järjestelmän toiminnan kannalta oleellisin osin tuomaan esiin taulukossa 4.1.

65 4. Arkkitehtuuri ja toteutus GIT:n Ruby sovellusrajapinta Grit on eräs Ruby ohjelmointikielille tarjottavista lukuisista gem kirjastoista. Kyseinen kirjasto tarjoaa tavan suorittaa Git versionhallintaan liittyviä toimenpiteitä Ruby ohjelmakoodin välityksellä. Grit gemin toiminta perustuu samojen komentoriviltä syötettävien git komentojen käyttämiseen, kuin millä käyttäjät tyypillisestikin suorittavat Git versionhallintaan liittyviä toimenpiteitä. Osa toimenpiteistä kuitenkin suoritetaan uudelleen Ruby ohjelmointikielellä kirjoitetun ohjelmakoodin välityksellä, käsitellen suoraan ohjelmavarastoa. Tästä rajapintaa käyttävien ohjelmoijien ei kuitenkaan tarvitse huolehtia, vaan heille tarjotaan helppokäyttöinen rajapinta, joilla operaatiot voidaan suorittaa. [17] 4.4 Allekirjoitusten laskeminen Tärkeimmät tietoturvallisuuteen liittyvät käsitteet ovat saatavuus (engl. availability), eheys (engl. integrity) ja luottamuksellisuus (engl. confidentiality). Saatavuuden käsitteeseen tutustuttiin jo aikaisemmin. Eheys käsitteen mukaan tietoa eivät saa päästä muuntelemaan sellaiset tahot, joilla siihen ei ole oikeutta. Lisäksi puutteet tiedon eheydessä tulee huomata. Luottamuksellisuus käsitteen mukaan vain sellaisten tahojen tulee voida päästä käsiksi tietoon, joilla tietoon on oikeus. Luottamuksellisuuden ja eheyden turvaamiseksi tietoa käyttäviltä tahoilta voidaan vaatia tunnistautumista (engl. authentication). Seuraavaksi perehdytään siihen, miten eheyttä ja luetattavuutta tuetaan VisualREST järjestelmässä. VisualREST järjestelmän REST rajapinnan autentikointi on saanut vaikutteita Amazonin S3 palvelun vastaavasta menetelmästä [2], jossa välitettävästä sisällöstä lasketusta MD5 muotoisesta tiivisteestä ja otsakkeiden sisällöstä lasketaan allekirjoitus (engl. Signature) HMAC-SHA1 algoritmia käyttäen. Algoritmi lisäksi myös salaa allekirjoituksen käyttäjän salaisella avaimella. Käyttäjälle luodaan, sekä julkinen (Access Key ID) että salainen avain (Secret Access Key), kun hän rekisteröityy Amazon Web Services kehittäjäksi. Julkinen avain välitetään pyyntöjen mukana parametrina, yhdessä lasketun allekirjoituksen ja Expires parametrin kanssa. Näistä jälkimmäinen määrää sen, kuinka kauan laskettu allekirjoitus on voimassa. Salainen avain on Amazon järjestelmien tiedossa, eikä sitä näin ollen koskaan tarvitse välittää pyynnön mukana. Palvelimen vastaanottaessa HTTP pyynnön, laskee se allekirjoituksen uudelleen. Näin käyttäjä voidaan autentikoida, ja lisäksi, koska allekirjoitus on sidottu välitettävään sisältöön, voidaan allekirjoituksen avulla myös varmistua sisällön eheydestä niin haluttaessa. [2] Taulukossa 4.2 on esitetty VisualREST järjestelmän REST rajapinnan autentikointiin käytettävät parametrit: auth_username, auth_timestamp ja auth_hash. Taulukon viimeisessä kohdassa on annettu esimerkki allekirjoituksen laskemisesta,

66 4. Arkkitehtuuri ja toteutus 60 Taulukko 4.2: REST rajapinnan autentikoinnin parametrit. Parametri i_am_client Kuvaus Tämä parametri kertoo, että ollaan käyttämässä REST rajapinnan asiakasohjelmille tarkoitettua autentikoitumistapaa. Parametrin arvo: true auth_username Parametrin avulla annetaan se käyttäjätunnus, jolle autentikointi suoritetaan. Esimerkki arvo: testuser auth_timestamp Unix tyyppinen aikaleima, jossa aika ilmaistaan sekunteina epoch hetkestä (00:00:00 UTC on January 1, 1970) alkaen. Palvelin voi joidenkin pyyntöjen yhteydessä laskea tämän parametrin avulla, onko allekirjoitus vielä voimassa. Esimerkki arvo: auth_hash Parametrina välitettävästä aikaleimasta, käyttäjän salasanasta, sekä pyynnön polusta SHA1 algoritmin mukaan laskettu allekirjoitus. Esimerkki allekirjoituksen laskemisesta: Pyynnön URL: Pyynnön polku (path): /files.atom Allekirjoitettava merkkijono (stringtosign): salasana/files.atom SHA1(stringToSign) Laskettu allekirjoitus: 58bbdfb5f5698a73443cba0c1e22fe9f99e37868

67 4. Arkkitehtuuri ja toteutus 61 käyttäen hyväksi taulukon muita esimerkki arvoja. Vaikka allekirjoituksen laskeminen ei perustukaan Amazon Web Services palveluiden tapaa avaimiin, noudattaa VisualRESTin autentikointi kuitenkin saman kaltaisia pääperiaatteita. Parametrit välitetään HTTP pyyntöjen mukana jokaista autentikointia vaativaa operaatiota suoritettaessa. 4.5 Tietosäiliöohjelman ja palvelimen yhteistoiminta Tässä kohdassa käydään vaiheittain läpi kaksi keskeisintä tietosäiliöohjelman ja VisualREST palvelimen välistä yhteistoimintaa vaativaa järjestelmän toimintoa. Alakohdassa on kuvattu initiaalimetatietojen välittämistä palvelimelle. Alakohdassa asiaksohjelman avulla noudetaan REST rajapintaa käyttäen sisällön essentia, joka on varastoituna tietosäiliöohjelmaan Metatietojen päivittäminen palvelimelle Kuva 4.7 esittää esimerkkinä toteutetun tietosäiliöohjelman ja VisualREST palvelimen välistä yhteistoimintaa vaiheittain. Kuvassa tietosäiliöohjelma huomaa sisällössä tapahtuneen muutoksia, ja välittää näihin muutoksiin liittyvät metatiedot palvelimelle. Vaiheet on esitetty ja niissä tapahtuvaa toimintaa kuvailtu alla olevassa listassa. Kuva 4.7: Metatietolistan päivittäminen.. 1. Tietosäiliöohjelma tarkkailee tasaisin väliajoin hakemistoa, jonka sisältö on päätetty tuoda VisualREST pilveen. Tässä kohdassa tietosäiliöohjelma huomaa muutoksen tarkkailtavassa sisällössä. 2. Huomatessaan muutoksen, tietosäiliöohjelma lisää tuoreimman sisällön version Git versionhallinnan ohjelmavarastoon, suorittaen commit operaation. 3. Sisällön ohjelmavarastoon lisäämisen jälkeen tietosäiliöohjelma generoi commit operaatioon liittyvän metatietolistan ja lähettää sen VisualREST palvelimelle

68 4. Arkkitehtuuri ja toteutus 62 REST rajapintaa hyväksi käyttäen. Hyväksyttyään metatietolistan parsittavaksi, VisualREST palvelin lähettää vastauksena HTTP paluukoodin 202 Accepted. 4. Palvelinohjelmisto parsii metatiedot, luoden niitä vastaavat mallit ja tallettaa niiden tiedot tietokantaan. 5. Kun metatietolista on saatu kokonaisuudessaan parsittua onnistuneesti, lähettää palvelinohjelmisto tietosäiliöohjelmalle viestin: parse successful <commit_hash>. 6. Palvelinohjelmisto pyytää tietosäiliöohjelmaa generoimaan esikatselukuvat lähettäen komennon: thumbs <commit_hash>. 7. Tietosäilöohjelma generoi esikatselukuvat, lähettäen ne yksitellen REST rajapinnan välityksellä palvelimelle Essentian välittäminen tietosäiliöohjelmalta asiakasohjelmalle Kuva 4.8 esittää asiakasohjelman, VisualREST palvelimen sekä tietosäiliöohjelman välistä yhteistoimintaa. Kuvassa REST rajapinnan asiakasohjelmana toimii web selain, joka lähettää HTTP pyynnön sisällön essentian noutamiseksi. Sisällön essentiaa ei kuitenkaan ole VisualREST palvelimen välimuistissa, joten se noudetaan tietosäiliöohjelmasta. Vaiheet on kuvailtu alla olevassa listassa. Kuva 4.8: Sisällön essentian välittäminen tietosäiliöohjelmalta web selaimelle. 1. Selain tai muu asiakasohjelma lähettää HTTP pyynnön palvelinohjelmiston REST rajapintaa käyttäen sisällön essentian noutamiseksi. 2. VisualREST palvelin lähettää tietosäiliöohjelmalle komennon: upload <tiedosto> <commit_hash>, kun se on ensin tehnyt seuraavat tarkastelut ja niiden ehdot täyttyvät: Sisältö on tuotu VisualREST pilveen.

69 4. Arkkitehtuuri ja toteutus 63 Käyttäjällä on autentikointiin perusteun käyttöoikeudet sisältöön. Sisältöä ei vielä löydy palvelimen välimuistista. Mikäli sisältö on välimuistissa, palautetaan se HTTP vastauksessa suoraan sieltä. Laite jossa sisällön essentia on varastoituna, on online tilassa. Mikäli tiedosto on kooltaan suurempi kuin kymmenen megatavua, palautetaan HTTP vastauksessa ilmoitus tästä asiasta, sekä paluukoodi 413 Request Entity Too Large. Ilmoituksessa asiakasta kehotetaan pyytämään tiedoston essentiaa myöhemmin uudelleen, kun se on ensin ladattu VisualREST palvelimen välimuistiin. Tiedoston koosta huolimatta tietosäiliöohjelmalle läheteään upload komento essentian lataamiseksi. 3. Tietosäiliöohjelman vastaanottaessa komennon, se päivittää online viestin avulla palvelimelle tiedon siitä, mitä sisällön essentiaa se on lataamassa. 4. Tietosäiliöohjelma lataa sisällön essentian palvelimelle. 5. Lataamisen päätyttyä tietosäiliöohjelma päivittää palvelimelle tiedon lataamisen valmistumisesta. 6. VisualREST palvelin palauttaa sisällön essentian HTTP vastauksessa.

70 64 5. ARVIOINTI Tässä luvussa pyritään arvioimaan VisualREST järjestelmän ominaisuuksia erilaisista näkökulmista. Esille pyritään tuomaan järjestelmän toteutuksessa havaittuja puutteita, sekä esittämään niille mahdollisia parannusehtotuksia jatkokehitysajatusten muodossa. Lisäksi arvioidaan sitä, miten hyvin käytetyt teknologiat soveltuvat tarkoituksiinsa, sekä tuomaan esille niiden käytössä ilmenneitä ristiriitaisuuksia. 5.1 Sisällönhallinnan ominaisuuksien toteutuminen Sisällön saatavuutta ja olemassa olon pysyvyyden turvaamista voidaan pitää sisällönhallinnan keskeisimpänä tavoitteena [22, s. 4]. Kaikkien sisällönhallintaan liittyvien ominaisuuksien voidaankin katsoa jossain määrin tähtäävän näihin samoihin tavoitteisiin. Seuraavaksi arvioidaan sitä, miten hyvin tässä työssä kuvaillun VisualREST järjestelmän ominaisuudet vastaavat aikaisemmin asetettuja sisällönhallintajärjestelmän ominaisuuksia Sisällön hakuominaisuudet Sisällönhallintaan liittyvän ominaisuuden 2 mukaan sisältöä tulee olla helppoa etsiä ja hakutuloksia navigoida. VisualREST järjestelmä tarjoaa REST rajapinnan sisällön hakemiseen. REST suunnitteluperiaatteiden mukainen rajapinta tarjoaa sekä käyttäjille että sovelluksille intuitiivisen ja tehokkaasti HTTP protokollan ominaisuuksia hyödyntävän tavan sisällön käsittelemiseen. REST suunnitteluperiaatteiden mukaan jokaisella järjestelmän resurssilla tulee olla yksilöllinen osoite, mutta se tarjoaa myös tavan jolla voidaan viitata resurssien hierakkiatasoille. Näitä tasoja hyödyntäen hauille voidaan muodostaa konteksti, jolloin hakujen tekeminen tehostuu ja tulokset vastaavat tarkemmin käyttäjän toiveita. Hakujen suorittaminen tapahtuu määrittelemällä ensin konteksti, johon haku kohdistetaan, ja tämän jälkeen määrittämällä URI osoitteen loppuun liitettävään kyselyosaan halutut hakuparametrit avain arvo pareina. Hakuja voidan suorittaa kaiken sisällöstä tuotetun metatiedon perusteella. REST rajapinnan käyttäminen saattaa niin kutsutuista tavallisista käyttäjistä tuntua kuitenkin turhan monimutkaiselta tai käytettävyydeltään huonolta tavalta hakujen suorittamiseen. Tästä johtuen VisualREST palvelinohjelmisto tarjoaa myös web käyttöliittymän, jonka avulla sisältöä voidaan selata ja kohdistaa siihen hakuja.

71 5. Arviointi 65 Lisäksi järjestelmän tietosisältöä voidaan tulevaisuudessa selata sille erikseen toteutettavien sovellusten avulla. Sisällönhallintaan liittyvän ominaisuuden 6 mukaan heterogeenisessä ympäristössä sijaitseville resursseille tulee tarjota yhtenäinen rajapinta. Myös tämä ominaisuus täyttyy VisualREST järjestelmässä, sillä sen rajapinnan toteutus noudattaa REST suunnitteluperiaatteita, joiden mukaan resursseille annettavien yksilöllisten osoitteiden tulee noudattaa yhtenäistä linjaa. Hakujen tulokset voidaan esittää käyttäjille HTML sivuina, jolloin hakutuloksia voidaan selata web käyttöliittymän ominaisuuksien avulla. Järjestelmän pääasiallinen käyttötarkoitus on kuitenkin tarjota rajapinta, jonka avulla erilaiset sovellusohjelmat pääsevät käyttämään pilvipalveluun tuotua sisältöä. Tästä syystä hakujen tulokset voidaan esittää myös laajalti tuetun Atom syötteen muodossa. Useat web selaimet ja syöteen lukuun erikoistuneet ohjelmat tarjoavat näin valmiin tuen sisällön selaamiseen. Atom syöte on muodoltaan XML dokumentti, jolloin sen sisällön parsiminen ohjelmallisesti on triviaali tehtävä, sillä lähes kaikille ohjelmointikielille löytyy valmiita kirjastoja XML dokumenttien parsimiseen Sisällön kuvaileminen Sisällönhallintaan liittyvän ominaisuuden 4 mukaan sisällöstä tulee tuottaa mahdollisimman paljon metatietoa ja liittää se sisältöön heti luonnin jälkeen. Työn alkupuollella kuvailtiin miten Curtis et al. olivat ratkaiseet ongelman toteuttamalla metatietojen tuottamiseen erillisen työkalun [9]. Tässä työssä kuvailtu tietosäiliöohjelma toimii jossain määrin samankaltaisten periaatteiden mukaisesti: huomatessaan muutoksia sisällössä, lisätään sisältö versionhallintaan, ja samalla sisällöstä tuotetaan niin kutsutut initiaalimetatiedot, jotka määrittelevät tietyn sisällön olemassaolon VisualREST järjestelmässä. Metatietoja ei kuitenkaan toistaiseksi pyritä tuottamaan automatisoidusti enempää, sillä on todettu, että essentiaa automatisoitujen prosessien avulla tutkimalla ei juurikaan voida tuottaa senkaltaista metatietoa, että käyttäjät voisivat hyödyntää sitä etsiessään sisältöä [9]. Initiaalimetatietojen lisäksi VisualREST tarjoaa mahdollisuuden kuvailla sisältöä mielivaltaisen metatiedon avulla. Käyttäjät voivat luoda omia metatietotyyppejään tai käyttää muiden käyttäjien luomia metatietotyyppejä kuvaillessaan sisältöä. Metatiedot ovat lisäksi heterogeenisiä, sillä metatietotyypit ja niiden arvot liitetään sisältöön vasta käyttäjien tai sovellusohjelmien asettaessa tiettyyn yksittäiseen sisältöön haluamansa metatietojen arvot. Lisäksi metatietotyyppejen liittymistä sisältöön voidaan hakujen yhteydessä säädellä harvan metatiedon käsitteen avulla. Näiden ominaisuuksien voidaan katsoa täyttävän sisällönhallintaan liittyvän ominaisuuden 5. Työn alkupuolella todettiin lisäksi, että käyttäjät pyrkivät tyypillisesti hakemaan

72 5. Arviointi 66 sisältöä esimerkiksi paikkojen todellisten nimien perusteella, ja että tämänkaltainen metatieto on ongelmallista liittää sisältöön automatisoitujen prosessien avulla [9]. Ongelmaa ollaan kuitenkin tutkimassa, ja ratkaisumenetelmäksi siihen ollaan kehittymässä eräänlaista sisällön käyttöympäristöön perustuvan kontekstin määrittäminen. Tähän ratkaisumenetelmään palataan jatkokehitysajatusten yhteydessä Sisällön saatavuuden turvaaminen Sisällönhallintaan liittyvän ominaisuuden 1 mukaan sisältö tulee sijoittaa välittömästi luonnin jälkeen sellaiseen paikkaan, josta siihen voidaan päästä aina käsiksi. Toisaalta sisällönhallintaan liittyvän ominaisuuden 3 mukaan sisällönhallintajärjestelmän tulee sijoittaa sisältö järjestelmän fyysisen rakenteen näkökulmasta lähelle sitä sijaintia, josta sisältöön tyypillisesti viitataan. VisualREST järjestelmä pyrkii vastaamaan näihin ominaisuuksiin jakamalla sisällön kahteen erilliseen osaan: metatietoon ja essentiaan. Metatietoja sisällöstä tuotetaan tietokoneissa ja mobiililaitteissa suoritettavien tietosäiliöohjelmien avulla, joista metatiedot välitetään välittömästi niiden luomisen jälkeen VisualREST palvelimelle. Näin ollen tieto sisällön olemassaolosta on kaikkien siihen käyttöoikeudet omaavien tahojen saavutettavissa lähes välittömästi sisällön luomisen jälkeen. Sisällön essentia puolestaan versioidaan tietosäiliöohjelman toimesta ja sijoitetaan ohjelman ylläpitämään versionhallintaan. Tietosäiliöohjelman vastuulla on ladata sisällön essentia palvelimen välimuistiin, vastaanottaessaan palvelimen lähettämän komennon. Toisaalta tietosäiliöohjelma on mahdollista toteuttaa myös siten, että se varastoi sisällön essentian halutessaan myös palvelimelle, tuottaen kuitenkin itse versiointiin liittyvät metatiedot. Näin ollen sisällön essentian saatavuudesta huolehtivat osaltaan sekä palvelinohjelmisto, että tietosäiliöohjelma. Tästä jaottelusta on hyötynsä, sillä usein saatetaan välttyä sisällön essentian turhalta lataamiselta palvelimelle hitaiden mobiiliyhteyksien välityksellä. Usein sisältöä esimerkiksi muokataan sen tuottaneella laitteella, ja näin ollen essentian turhalta välittämiseltä vältytään, sillä palvelimelle voidaan välittää vain se versio, josta muut käyttäjät ovat kiinnostuneita. Toisaalta tieto sisällön olemassaolosta ja sen versioista on aina saatavilla, ja tietosäiliöohjelmaa voidaan yrittää xmpp protokollan välityksellä välitettävien viestien avulla komentaa lataamaan palvelimelle juuri haluttu versio sisällön essentiasta. Lisäksi, kuten aikaisemmin mainittiin, on tietosäiliöohjelmalla mahdollisuus päättää lataako se sisällön essentian palvelimelle heti luomisen jälkeen, vai vasta komennettaessa. Älykäs tietosäiliöohjelma voisi antaa käyttäjälle vapauden valita milloin sisällön essentia palvelimelle ladataan, tai esimerkiksi tarkkailla käytössä olevia verkkoyhteyksiä, ja nopean yhteyden saadessaan suorittaa essentian lataamisen. Tämänkaltaisessa yhteistoiminnassa VisualREST palvelinohjelmiston tehtävänä

73 5. Arviointi 67 on välittää sisällön essentian lataamiseen liittyviä komentoja ja vastaanottaa tietosäiliöohjelmien lataamaa essentiaa. Lisäksi palvelinohjelmisto tarkkailee laitteiden online tilaa, ja antaa käyttäjille selkeää palautetta sisällön saatavuudesta esimerkiksi sellaisissa tilanteissa, joissa essentiaa ei ole palvelimen välimuistiin ladattu, eikä sitä hallussaan pitävä laite ole tavoitettavissa. Sisällön saatavuuden voidaan katsoa yllä mainittujen seikkojen vuoksi olevan varsin moniulotteinen ongelma, ja sisällön hallintaan liittyvien ominaisuuksien 1 ja 3 täyttyminen riippuu lukuisista asioista. Saatavuuteen vaikuttavat ainakin tietosäiliöohjelman toteutus ja sitä suorittava laite, laitteen käyttäjä ja hänen käyttötapansa, sekä käytössä olevat verkkoyhteydet. Jatkossa sisällön saatavuuteen tulee mukaan vielä uusia puolia, sillä jatkokehitysajatuksena on kehittää sisällön essentian välittämistä suoraan laitteiden välillä Sisällön käyttäjäkohtaiset asetukset Sisällönhallintaan liittyvän ominaisuuden 7 mukaan hajautetun sisällönhallintajärjestelmän tulee tarjota tehokas tapa, jolla tietosisältöä voidaan hakea (engl. access) heterogeenisessä ympäristössä käyttäjäkohtaisten asetusten perusteella. VisualREST järjestelmässä näitä käyttäjäkohtaisia asetuksia sekä ylläpidetään että valvotaan palvelinohjelmiston toimesta. Tuodakseen sisältöä VisualREST järjestelmään, käyttäjän tulee sekä luoda käyttäjäprofiili että rekisteröidä tietosisällön tuomiseen käyttämänsä tietosäiliöohjelma VisualREST palvelimelle. Näiden toimenpiteiden aikana käyttäjä valitsee itselleen yksikäsitteisen käyttäjätunnuksen koko järjestelmän kontekstissa, ja laitteelle yksikäsitteisen laitetunnuksen käyttäjätunnuksen kontekstissa. Lisäksi käyttäjäprofiilin luominen on edellytyksenä sille, että yksityiseksi määriteltyä sisältöä voitaisiin jakaa käyttäjän kanssa. Käyttäjän on mahdollista laajentaa käyttäjäprofiiliaan luomalla siihen uusia käyttäjäryhmiä. Näihin ryhmiin käyttäjä valitsee haluamansa muut järjestelmän käyttäjät, jonka jälkeen käyttäjäryhmään kuuluvilla käyttäjillä on oikeudet kaikkeen siihen sisältöön, johon myös käyttäjäryhmälle on myönnetty käyttöoikeudet. Tällä käyttäjien ryhmittelyllä säästytään suurelta määrältä manuaalista työtä, sillä käyttäjän ei tarvitse erikseen ja yksitellen määritellä jokaisen käyttäjän ja sisällön välisiä käyttöoikeuksia. Toistaiseksi järjestelmään ei ole toteutettu käyttöoikeuksien automatisoitua asettamista käyttöoikeuspolitiikoiden avulla. Kuten jo aikaisemmin mainittiin, ollaan VisualREST järjestelmään kuitenkin kehittämässä sisällön käyttöympäristöön perustuvaa kontekstia, jonka avulla sisältöön voidaan automatisoidun prosessin avulla liittää käyttöympäristöä kuvailevaa metatietoa. Tähän samaiseen toiminnallisuuteen ollaan lisäksi kehittämässä käyttöoikeuksien asettamista. Toiminnallisuutta kuvaillaan jatkokehitysajatusten yhteydessä tarkemmin. Lisäksi järjestelmään ollaan ke-

74 5. Arviointi 68 hittämässä mekanismejä, joiden avulla käyttäjät voivat rekisteröityä vastaanottamaan ilmoituksia (engl. notification), kun heitä kiinnostavassa sisällössä tapahtuu muutoksia. Myös tätä toiminnallisuutta kuvaillaan jatkokehitysajatusten yhteydessä. 5.2 Teknologioiden soveltuvuus tarkoituksiinsa Tässä kohdassa arvioidaan miten hyvin VisualREST järjestelmän toteuttamisessa käytetyt teknologiat soveltuvat tarkoituksiinsa. Esille on pyritty erityisesti nostamaan teknologioiden soveltamisen yhteydessä ilmenneitä ongelmia ja ristiriitaisuuksia. Lisäksi ongelmiin on pyritty antamaan ratkaisuehdotuksia REST suunnitteluperiaatteiden noudattaminen Aikaisemmin todettiin, että REST rajapinta tarjoaa intuitiivisen ja tehokkaan rajapinnan sisällön etsimiseen ja käsittelemiseen. REST suunnitteluperiaatteiden mukaisen rajapinnan todettiin myös tarjoavan yhtenäisen rajapinnan järjestelmän resursseille: resursseihin viittaminen on helppoa, kun kaikilla resursseilla ja aliresurseilla on yksilöllinen ja yhtenäistä linjaa noudattava URI osoite. Lisäksi toteutuksessa käytetty Ruby on Rails sovelluskehys on tukee hyvin REST suunniteluperiaatteita [35, s.439]. REST suunnitteluperiaatteita noudattava rajapinta soveltuukin erinomaisen hyvin sisällönhallintajärjestelmän rajapinnaksi. Eräissä tilanteissa REST suunnitteluperiaatteiden mukainen tilattomuuden vaatimus näyttää kuitenkin olevan epäilyttävällä tavalla ristiriidassa VisualREST järjestelemän toiminnan kanssa: REST suunnitteluperiaatteet kieltävät palvelinta ylläpitämästä asiakasohjelman tilaa. VisualREST järjestelmä puolestaan pitää asiakasta, jota tässä tapauksessa vastaa laite resurssi, yhdenveroisena resurssina muihin järjestelmän resursseihin verrattuna. Näin ollen tietosäiliöohjelman päivittäessä itseään vastaavaa laite resurssia, päivittää se eräällä tapaa omaa tilaansa palvelimelle. Näin toimitaan esimerkiksi kun tietosäiliöohjelma ilmoittaa online tilastaan tasaisin väliajoin päivittäen laite resurssiin liittyvää last_seen metatietoa. REST periaatteiden mukaan resurssin tilaa on luonnollisesti tarkoitettu päivitettävän, mutta suunnitteluperiaatteet eivät suoranaisesti kerro miten asiakasohjelman pitämiseen resurssina tulisi suhtautua. Toisaalta tämä periaatteellinen ongelma voidaan myös kiertää ilmaisemalla asia siten, ettei laite resurssi millään tavoin vastaa tietosäiliöohjelmaa, vaan kuvaa ainoastaan sitä laitetta tai ympäristöä, jossa tietosäiliöohjelmaa suoritetaan. Tällöin tietosäiliöohjelma ainoastaan päivittää tähän laite resurssiin liittyvää metatietoa. Tätä ristiriitaa tullaan jatkossa kuitenkin selvittämään tarkemmin, ja erään mahdollisen ratkaisun ongelmaan saattaakin tarjota XMPP protokollan käyttäminen laitteiden tilan seurantaan. [27, s ]

75 5. Arviointi 69 Toinen REST suunnitteluperiaatteita koskettava ristiriita liittyy tapaan, jolla VisualREST järjestelmä välittää sisällön essentiaa tietosäiliöohjelmalta palvelimelle. VisualREST järjestelmän tämänhetkisessä totoutuksessa tiedosto resurssi tulee asettaa erityiseen tilaan erillisen HTTP pyynnön avulla, jotta se suostuu vastaanottamaan tietosäiliöohjelman lataamaan sisällön essentiaa. Tämä toiminta ei sinänällään ole REST suunnitteluperiaatteita vastaan. Ristiriita ilmeneekin siinä, ettei tietosäiliöohjelman lähettämä sisällön essentian sisältämä HTTP pyyntö sisällä kaikkea tarvittavaa informaatiota, vaan palvelimen toiminta on riippuvainen edellisestä pyynnöstä. Tämä pyyntö ei näin ollen tapahdu täysin eristettynä (engl. isolation) muista pynnöistä, kuten REST-suunnitteluperiaatteiden mukaan tulisi. Ongelmaa voidaan kuitenkin tietyllä tapaa pitää toteutetun järjestelmän kannalta erikoistapauksena, eikä mikään toisaalta pakota lataamaan sisällön essentiaa palvelimelle juuri REST rajapintaa käyttäen. Kyseinen ongelma ratkaistaneen tulevaisuudessa, sillä resurssien välittämiseen liittyvä toteutus tulee muuttumaan suoraan laitteiden väliseksi toiminnaksi. [27, s ] Hajautetun järjestelmän ominaisuuksien toteutuminen VisualREST järjestelmän voidaan katsoa fyysiseltä rakenteeltaan olevan varsin heterogeeninen, sillä järjestelmän fyysinen rakenne muuttuu käytännössä aina, kun uudentyyppiset tietokoneet käyttävät järjestelmää REST rajapinnan välityksellä tai tuovat järjestelmään sisältöä niille toteutettujen tietosäiliöohjelmien välityksellä. VisualREST järjestelmää käyttämään on käytännössä mahdollista liittää myös kokonaisia erillisiä järjestelmiä. Järjestelmän REST rajapinta onkin suunniteltu erityisesti sovellusohjelmia silmällä pitäen. Rajapintaa käytettäessä VisualREST palvelin toimii eräänlaisena välikerroksena, piilottaen asiakasohjelmilta taustalla olevan järjestelmän hetogeenisen fyysisen rakenteen. Fyysistä rakennetta ei ole kuitenkaan haluttu täydellisesti piilottaa, sillä järjestelmän toimminnan ymmärtäminen vaatii tietyllä tapaa hahmottamaan järjestelmän resurssien hierarkkista rakennetta. Sen sijaan fyysinen rakenne näkyy käyttäjille tietyllä tapaa homogeenisena laite resurssien joukkona. Tuntumattomuus on haluttu jättää tälle tasolle, sillä näin ollen järjestelmän käyttäjät voivat halutessaan jäljittää sitä, mihin laitteessen jokin sisältö on talletettu. Tästä saattaa olla apua esimerkiksi tilanteissa, joissa jokin sisällön essentiaa hallussaan pitävä laite on toistuvasti offline tilassa. Tanenbaum ja Steen kirjoittavatkin, että järjestelmän täydelliseen tuntumattomuuteen ja suorituskykyyn liittyy tietynlainen vaihtokauppa, ja esimerkkeinä he mainitsevat juuri resurssien saatavuuteen liittyviä seikkoja [33, s. 7 8]. VisualREST palvelimen toimimista välikerroksena on esitetty kuvassa 5.1. Hajautetun järjestelmän kuvauksen yhteydessä mainittiin myös, että ohjelmiston

76 5. Arviointi 70 Kuva 5.1: VisualREST järjestelmän voidaan nähdä rakentuvan myös kerroksittain. tehtävänä on toimia eräänlaisena resursseja automatisoidusti kontrolloivana työkaluna, jonka avulla järjestelmän käyttäjät voivat käyttää samoja järjestelmän ylläpitämiä resursseja. Tämän hajautetun järjestelmän ominaisuuden voidaan katsoa VisualREST järjestelmässä toteutuvan, sillä se tarjoaa yhtenäisen rajapinnan kaikkien resurssien käsittelemiseen. VisualREST järjestestelmä tarjoaa lisäksi helpon tavan liittää järjestelmään uusia laitteita, joiden sisältö halutaan tuoda osaksi pilvipalvelua. Sisällöstä luotuja uusia resursseja voidaan välittömästi niiden luonnin jälkeen hyödyntää samojen toimintojen avulla, kuin vanhojakin resursseja. Järjestelmän suorituskyvyn muutosta, eli skaalautuvuutta erittäin suurilla laite ja sisältö resurssien määrällä ei kuitenkaan ole toistaiseksi vielä mitattu. Välikerrokseen perustuva rakenne tukee osaltaan järjestelmän avoimuutta, sillä palvelinohjelmiston REST rajapinta tarjoaa löyhän sidonnan ansiosta mahdollisuuden erilaisten tietosäilöohjelmien, sekä muidenkin asiakasohjelmien toteuttamiselle. Kuten aikaisemminkin on todettu, tarjoavat lähes kaikki ohjelmointikielet helpon tavan HTTP protokollan käyttämiseen, sekä XML muotoisten tietojen parsimiseen. Avoimuutta kuitenkin rajoittaa tietosäiliöohjelmalle asetettu vaatimus Git versionhallinnan käyttämisestä Git versionhallintaan liittyvät ongelmat VisualREST järjestelmä asettaa tietosäiliöohjelmalle vaatimuksen, jonka mukaan sen tulee huolehtia sisällön versioinnista Git versionhallintatyökalua käyttäen. Tätä työkalua käytetään lisäksi myös sisältöön liittyvien niin kutsuttujen initiaalimetatietojen tuottamiseen, jotka määrittelevät yksittäisen sisällön olemassaolon VisualREST järjestelmässä. Git versionhallinnan käyttäminen saattaa kuitenkin joissain tilanteissa tuottaa ongelmia, sillä sitä ei ole toteutettu useimmille älypuhelimille. Tietosäiliöohjelman vaatimusten yhteydessä mainittiin kuitenkin, ettei Git versionhallinnan käyttäminen ole täysin pakollista. Sen sijaan riittää että tietosäiliöohjelma tuotaa vastaavat metatiedot, sekä huolehtii sisällön essentian säilyttämisestä ja