Niko Mäkitalo REST–POHJAINEN
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 5.5.2010 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. 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. 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 2010. Niko Mäkitalo [email protected] 040 5770014 V SISÄLLYS 1. Johdanto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Taustaa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Hajautettu järjestelmä . . . . . . . . . . . . . . . . . . 2.2 Pilvilaskenta . . . . . . . . . . . . . . . . . . . . . . . 2.3 Teknologiat pilvipalveluiden taustalla . . . . . . . . . 2.4 REST–suunnitteluperiaatteet . . . . . . . . . . . . . . 2.5 Sisällönhallinta . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Sisältö, metatieto ja essentia . . . . . . . . . . . . 2.5.2 Sisällönhallintajärjestelmien ominaisuuksia . . . . 2.5.3 Sisällön hakeminen ja hakutulosten esittäminen . 2.5.4 Metatietojen tuottaminen . . . . . . . . . . . . . 2.5.5 Sisällön saatavuus . . . . . . . . . . . . . . . . . . 2.5.6 Sisällön versiointi . . . . . . . . . . . . . . . . . . 2.5.7 Sisällön oikeuksien hallinta . . . . . . . . . . . . . 3. Järjestelmän yleiskuvaus . . . . . . . . . . . . . . . . . . . . 3.1 Palvelinohjelmiston yleiskuvaus . . . . . . . . . . . . . 3.2 Tietosäiliöohjelman yleiskuvaus . . . . . . . . . . . . . 3.2.1 Vaatimukset tietosäiliöohjelmalle . . . . . . . . . . 3.2.2 Esimerkkitoteutuksen yleiskuvaus . . . . . . . . . 3.3 REST sisällönhallinnan näkökulmasta . . . . . . . . . 3.4 Palvelinohjelmiston REST–rajapinnan kuvaus . . . . . 3.4.1 Konteksti: käyttäjätunnus . . . . . . . . . . . . . 3.4.2 Konteksti: käyttäjätunnus ja ryhmätunnus . . . . 3.4.3 Konteksti: käyttäjätunnus ja laitetunnus . . . . . 3.4.4 Konteksti: käyttäjätunnus, laitetunnus ja tiedosto 3.4.5 Muut kontekstit ja resurssit . . . . . . . . . . . . 3.4.6 HTTP–paluukoodit . . . . . . . . . . . . . . . . . 3.4.7 URI–osoitteiden kyselyosa . . . . . . . . . . . . . 4. Arkkitehtuuri ja toteutus . . . . . . . . . . . . . . . . . . . 4.1 VisualREST–palvelimen arkkitehtuuri . . . . . . . . . 4.1.1 Toteutusteknologiana Ruby on Rails . . . . . . . . 4.1.2 Fyysinen näkymä . . . . . . . . . . . . . . . . . . 4.1.3 Palvelinohjelmiston tietosisältö ja mallit . . . . . . 4.1.4 Palvelinohjelmiston rakenne . . . . . . . . . . . . 4.2 Tietosäiliöohjelman esimerkkitoteutus . . . . . . . . . 4.2.1 Rakenne ja toimintaperiaatteet . . . . . . . . . . . 4.2.2 Tietosäiliöohjelman ylläpitämät tiedostot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 4 6 7 9 13 14 15 16 17 19 20 22 24 25 27 28 31 32 35 35 37 38 40 41 42 44 46 46 46 48 49 52 54 54 55 VI 4.3 Versionhallintajärjestelmänä GIT . . . . . . . . . . . . . . 4.3.1 Versioinnin toteuttaminen GIT:n avulla . . . . . . . . 4.3.2 GIT:n Ruby–sovellusrajapinta . . . . . . . . . . . . . 4.4 Allekirjoitusten laskeminen . . . . . . . . . . . . . . . . . 4.5 Tietosäiliöohjelman ja palvelimen yhteistoiminta . . . . . 4.5.1 Metatietojen päivittäminen palvelimelle . . . . . . . . 4.5.2 Essentian välittäminen tietosäiliöohjelmalta asiakasohjelmalle . . . . . . . . . . . . . . . . . . . . 5. Arviointi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Sisällönhallinnan ominaisuuksien toteutuminen . . . . . . 5.1.1 Sisällön hakuominaisuudet . . . . . . . . . . . . . . . 5.1.2 Sisällön kuvaileminen . . . . . . . . . . . . . . . . . . 5.1.3 Sisällön saatavuuden turvaaminen . . . . . . . . . . . 5.1.4 Sisällön käyttäjäkohtaiset asetukset . . . . . . . . . . 5.2 Teknologioiden soveltuvuus tarkoituksiinsa . . . . . . . . . 5.2.1 REST–suunnitteluperiaatteiden noudattaminen . . . 5.2.2 Hajautetun järjestelmän ominaisuuksien toteutuminen 5.2.3 Git–versionhallintaan liittyvät ongelmat . . . . . . . . 5.2.4 Ruby ja mobiili ympäristö . . . . . . . . . . . . . . . 5.3 Jatkokehitysajatukset . . . . . . . . . . . . . . . . . . . . 5.3.1 Käyttöympäristöön perustuva konteksti . . . . . . . . 5.3.2 Ilmoitukset . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Essentian välittäminen laiteelta laitteelle . . . . . . . 6. Yhteenveto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Esimerkki metatietolista . . . . . . . . . . . . . . . . . . . . . B. Hakutulosten Atom–syöte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 57 59 59 61 61 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 64 64 64 65 66 67 68 68 69 70 71 72 72 72 73 74 79 80 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- 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- 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. 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 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 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] 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. 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 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- 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) 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. 86–89] 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. 94–95] 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- 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 HTTP:n 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 2. Taustaa 13 kuten aikaisemmin mainittiin, uuden aliresurssin luomista osoitteen viittaamalle resurssille. [27, s. 99–100] Toisinaan REST–rajapintaa toteutettaessa eteen tulee tilanteita, joissa on lähes mahdotonta välttyä tyypillisen RPC–toiminnallisuuden1 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ä. 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. 2.5.1 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ä 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] 2.5.2 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]. 2. Taustaa 16 4. 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ä. 2.5.3 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. 90–91] 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. 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. 2.5.4 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 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 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ä asioita3 . 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. 2.5.5 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 saat2 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? 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. 2.5.6 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 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 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. 2.5.7 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ää 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. 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. 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 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- 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- 3. Järjestelmän yleiskuvaus 28 sa. Voidakseen toteuttaa sille asetetut vaatimukset, tietosäiliöohjelman tulee lisäksi toteuttaa taulukoissa 3.1 – 3.4 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. 3.2.1 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. 3. Järjestelmän yleiskuvaus 29 4. Ohjelman tulee toteuttaa taulukoissa 3.1 – 3.4 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 d8f7f710ee58a8590c271f059406293d63112a14 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 8b10da93353e0e27ef9bdb802f835c92ca423728 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 3. Järjestelmän yleiskuvaus 3.2.2 31 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- 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ää 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- 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ää. 3. Järjestelmän yleiskuvaus 3.4 35 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 3.4.6 ja URI–osoitteen kyselyosan avulla tarkentavien hakuriteerien määrittämistä on käsitelty alakohdassa 3.4.7. Polkujen kuvausten yhteydessä mainitaan, mikäli operaation tekeminen vaatii autentikointia. REST–rajapinnan käyttämää autentikointimenetelmää on kuvattu tarkemmin jäljempänä. 3.4.1 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 3.5 – 3.7 on käyty läpi käyttäjä–kontekstin alaisuuteen kuuluva osuus REST–rajapinnasta. 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. 3. Järjestelmän yleiskuvaus 3.4.2 37 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 3.8 – 3.9 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. 3. Järjestelmän yleiskuvaus 3.4.3 38 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 3.10 – 3.12 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ä. 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: 23.75 uploading_file_hash: ae087ff1a4dff391bfe286156a61fb1a1470a6e6 3. Järjestelmän yleiskuvaus 3.4.4 40 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 3.13 – 3.15 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. 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. 3.4.5 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 3.4.7. 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ä. 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. 3.4.6 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ä, 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 412. 413 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. 3. Järjestelmän yleiskuvaus 3.4.7 44 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 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. 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. 4.1.1 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 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ä HTTP:n 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). 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. 4.1.2 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 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. 4.1.3 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- 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, 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- 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ä. 4.1.4 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- 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 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 3.1 – 3.4. 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. 4.2.1 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 3.2.1 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- 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. 29–32] 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. 29–32] 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ä. 4.2.2 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- 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- 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] 4.3.1 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 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. Käsite tree Palvelinohjelmisto - blob Kuvaa sisällön versiokohtaiset initiaalimetatiedot. Kokoaa yhteen joukon tiettyyn Sisältää osoittimen sitä hakecommittiin liittyviä metatietoja. mistoa kuvaavaan tree–objektiin, jonka sisältö tuodaan versionhallintaan. commit Git Kuvaa hakemiston tai alihakemiston sisällön. Sisältää osoittimia blob–objekteihin tai toisiin tree– objekteihin. Sisältää tiedoston essentian. 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. 4. Arkkitehtuuri ja toteutus 4.3.2 59 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, 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: 1288094240 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: http://visualrest.cs.tut.fi/files.atom?type=jpg Pyynnön polku (path): /files.atom Allekirjoitettava merkkijono (stringToSign): 1288094240salasana/files.atom SHA1(stringToSign) Laskettu allekirjoitus: 58bbdfb5f5698a73443cba0c1e22fe9f99e37868 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 4.5.1 on kuvattu initiaalimetatietojen välittämistä palvelimelle. Alakohdassa 4.5.2 asiaksohjelman avulla noudetaan REST–rajapintaa käyttäen sisällön essentia, joka on varastoituna tietosäiliöohjelmaan. 4.5.1 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 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. 4.5.2 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. 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. 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. 5.1.1 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. 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. 5.1.2 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 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ä. 5.1.3 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ä 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ä. 5.1.4 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- 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. 5.2.1 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. 90–91] 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. 86–87] 5.2.2 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 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ä. 5.2.3 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 5. Arviointi 71 versioinnista. Tämä vaatimus on kuitenkin täysin mahdollista täyttää, sillä käytännössä tietosäiliöohjelman tulee vain osata laskea sisällön essentiaan liittyvä tiiviste (blob_hash) samojen periaatteiden mukaan, kuin Git–versionhallinta sen laskee: blob_hash = sha1("blob " + <sisällön koko> + "\0" + <essentia>) Toinen versiointiin liittyvä tiiviste on commit_hash, jonka Git–versionhallinta laskee commit–operaation sisällöstä. VisualREST–järjestelmän toiminnan kannalta ei kuitenkaan ole merkitystä, kuinka tietosäiliöohjelma tämän tiivisteen laskee, kunhan se on yksilöllinen muihin saman tietosäiliöohjelman laskemiin tiivisteisiin verrattuna. Se voitaisiin näin ollen laskea esimerkiksi kaikkien muuttuneiden sisältöjen blob_hash–tiivisteisteiden avulla, esimerkiksi seuraavalla tavalla: commit_hash = sha1("commit " + <sisältöjen koko yhteensä> + "\0" + <blob_hash> + <blob_hash> + <blob_hash>) Näiden versiointiin liittyvien metatietojen lisäksi tietosäiliöohjelman tulisi joko varastoida sisältöjen versioiden essentia paikallisesti, tai vaihtoehtoisesti ladaten sen aina VisualREST–palvelimelle välittömästi luonnin jälkeen. Git–versionhallinnan käyttäminen ei tässä esille tuotujen syiden perusteella ole täysin ongelmatonta. Tästä syystä myös tähän ongelmaan tullaan jatkossa perehtymään tarkemmin. Versiointi on kuitenkin kohtuullisella vaivannäöllä mahdollista toteuttaa itsekin. Eräs mahdollisuus saattaisikin olla tähän liittyvän kirjaston toteuttaminen yleisimmille älypuhelinalustoille. 5.2.4 Ruby ja mobiili ympäristö Tietosäiliöohjelman esimerkkitoteuksessa on käytetty Ruby–ohjelmointikieltä. Tämä toteutus ei kuitenkaan sovellu käytettäväksi kaikissa ympäristöissä, sillä Ruby– ohjelmointikieltä eivät esimerkiksi useimmat älypuhelimet suoraan tue. Kuvassa 3.5 esitettiin, miten Nokia N900 –älypuhelimella suoritetaan esimerkkinä toteutettua tietosäiliöohjelmaan. Kyseisen puhelimen Maemo–käyttöjärjestelmä mahdollistaa myös Ruby–ohjelmointikielellä toteutettujen sovellusten suorittamisen. Mobiililaitteiden heikosta Ruby–ohjelmointikielen tuesta johtuen tässä työssä onkin pyritty määrittelemään tietosäiliöohjelmalta vaadittavat ominaisuudet. Nämä vaatimuksia vastaava tietosäilöohjelma onkin täysin mahdollista toteuttaa millä tahansa yleisimmin käytetyllä ohjelmointikielellä. Lisäksi tietosäiliöohjelmasta ollaan parhaillaan kehittämässä Python–ohjelmointikielellä toteutettua versiota. 5. Arviointi 5.3 72 Jatkokehitysajatukset Tässä kohdassa kuvaillaan järjestelmän kehittämiseksi suunniteltuja jatkokehitysajatuksia. Näiden ajatusten yhteydessä pyritään lisäksi myös kuvailemaan sitä, minkälaisten teknologioiden avulla jatkokehitysajatukset tullaan mahdollisesti toteuttamaan. Alakohdassa 5.3.3 on esitetty myös jotain hylättyjä ratkaisuvaihtoehtoja, joiden avulla sisällön essentian välittämistä laitteiden välillä on jo kokeiltu. 5.3.1 Käyttöympäristöön perustuva konteksti Aikaisemmin tässä työssä on jo todettu, että automatisoitujen prosessien avulla sisällöstä on hyvin vaikeaa tuottaa sellaista metatietoa, jota käyttäjät voisivat käyttää hyväkseen sisältöä etsiessään. Esimerkiksi digitaalikameran valokuville generoidaan tyypillisesti päivämääristä ja jouksevista numeroista koostuvia nimiä. Tämänkaltaiset nimet ovat ihmisille haastellisia muistettavia, eikä niiden perusteella tästä johtuen usein voida etsiä juuri haluttuun asiaan liittyvää sisältöä. Sen sijaan käyttäjän on helpompaa muistaa, että hän on esimerkiksi ottanut valokuvia jossain tietyssä tilanteessa, tai ainakin hänellä on käsitys siitä minkälaiseen yhteyteen nämä valokuvat liittyvät. Käyttötilanteesta tai -yhteydestä käytetään tässä ilmaisua käyttökonteksti. Tämänkaltaisen käyttökontekstin liittäminen sisältöön tulisi tapahtua sisällön luonnin yhteydessä, mitä tukee myös sisällönhallintaan liittyvä ominaisuus 4. VisualREST–järjestelmään ollaan kehittämässä toiminnallisuutta tässä kuvatun käyttökontekstin lisäämiseksi sisältöön. Toiminnallisuuden ideana on, että sisältöä tuottavassa laitteessa määritellään ennalta se käyttökonteksti, johon laitteen seuraavaksi tuottama sisältö liittyy. Kun laite seuraavan kerran tuottaa sisältöä, kuvaillaan tämä sisältö automatisoidun prosessin avulla käyttökontekstiin määriteltyjen metatietojen avulla. Metatiedot voivat olla käytännössä mitä tahansa, mutta usein niihin on suositeltavaa liittää ainakin tapahtumapaikan todellinen nimi, sillä käyttäjät pyrkivät tyypillisesti etsimään sisältöä tämän tiedon perusteella. Käyttökonteksti on mahdollista liittää tuotettuun sisältöön myös jälkikäteen. Käyttäjät voivat jakaa luomiaan käyttökonteksteja lähetämällä siihen kutsuja muille VisualREST–järjestelmän käyttäjille. Lisäksi käyttäjät voivat määrittää luomansa käyttökontekstit yksityisiksi, jolloin sisällön liittäminen käyttökontekstiin myöntää sisältöön liittyvät käyttöoikeudet automatisoidun prosessin avulla kaikille käyttökontekstiin kutsutuille henkilöille. 5.3.2 Ilmoitukset VisualREST–palvelimen tehtävänä on huolehtia sisällön saatavuudesta mahdollisimman hyvin. Se tarjoaakin rajapinnan jolla sisältöä voidaan etsiä, ja jonka avulla 5. Arviointi 73 hakutulokset voidaan esittää sekä käyttäjille että toisille sovelluksille. Tulokset voidaan pyytää Atom–syötteen muodossa, jonka lukemista tukevat monet valmiit sovellusohjelmat. Atom–syötteessä tapahtuvia muutoksia seuraamalla on mahdollista tarkkailla myös sisällössä tapahtuvia muutoksia. Kun suuri joukko asiakkaita toistuvasti ja tasaisin väliajoin tiedustelee palvelimelta sisällössä tapahtuneita muutoksia, aiheuttaa tämä ylimääräistä kuormistusta palvelimelle. Tehokkaampi tapa olisikin, jos palvelin ilmoittaisi asiakkaille sisällössä tapahtuneista muutoksista. XMPP–protokolla tarjoaa tämänkaltaiseen tarkoitukseen erinomaisesti sopivan kanavan, jonka välityksellä palvelinohjelmisto voi lähettää ilmoituksia (engl. notification) asiakasohjelmille. Ilmoituksia voidaan lähettää samaa kanavaa pitkin, kuin muutkin palvelinohjelmiston tietosäiliöohjelmalle välittämät komennot kulkeutuvat, käyttäen hyväksi tietosäiliöohjelmalle rekisteröinnin yhteydessä luotua XMPP– tunnusta. Lisäksi on mahdollista luoda myös jokaiselle käyttäjälle oma XMPP– tunnus, jota voitaisiin käyttää ilmoitusten välittämiseen. XMPP–protokolla tarjoaa kuitenkin myös monipuolisempia tapoja ilmoitusten lähettämiseen. Eräs tällainen tapa on XMPP–protokollan Publish-Subscribe–laajennus [23], joka on optimoitu välittämään viestejä yhdeltä käyttäjältä usealle käyttäjälle. Tämän laajennuksen tarjoamia mahdollisuuksia ilmoitusten välittämiseksi tullaan jatkossa tutkimaan tarkemmin. Ilmoitusten välittäminen on tarkoituksena toteuttaa aluksi yllä kuvattua käyttökontekstia silmällä pitäen, ja laajentaa tämän jälkeen vähitellen myös muihin toimintoihin. 5.3.3 Essentian välittäminen laiteelta laitteelle VisualREST–järjestelmän tämänhetkisessä toteutuksessa sisällön essentia välitetään aina palvelinohjelmiston kautta. Järjestelmän toimintafilosofia on kuitenkin, että sisällön essentia olisi ensisijaisesti talletettuna sen tuottaneella laitteella. Tästä johtuen olisikin tehokkaampaa, mikäli sisällön essentia voitaisiin välittää suoraan tietosäiliöohjelmalta sitä käyttämään pyrkivälle asiakasohjelmalle. Ongelmaa on yritetty ratkaista tietosäiliöohjelman ylläpitämän web–palvelimen avulla, käyttäen hyväksi WEBRick–palvelinkirjastoa. Tämä ratkaisuvaihtoehto jouduttiin kuitenkin hylkäämään, sillä verkkojen rakenne ja tietoturvaratkaisut estivät useissa tapauksissa asiakasohjelmia saamasta yhteyttä tietosäiliöohjelman palvelimeen. Lisäksi essentian välittämistä on kokeiltu XMPP–protokollan välityksellä, mutta tämä välityskanava on alustavissa testeissä osoittautunut hitaaksi tiedonsiirtokapasiteetiltaan. Jatkossa tullaan kuitenkin vielä tutkimaan tarkemmin XMPP–protokollan käyttämistä tiedonsiirtokanavana. Lisäksi myös muiden protokollien käyttämistä tullaan tutkimaan. 74 6. YHTEENVETO Sisällönhallinta hajautetussa heterogeenisessä ympäristössä on ajankohtainen ja kasvava ongelma. Tutkimusyhtiö IDC on useana vuonna tehnyt tutkimuksen maailmassa olevan digitaalisen tiedon määrästä [19]. Näiden tutkimusten perusteella digitaalisen tiedon määrä kaksinkertaistuu noin puolentoista vuoden välein, ja on tämän hetkisen arvion mukaan noin 800 miljardia gigatavua. Tästä tiedosta luonnollisesti vain pieni osuus on yksittäisten käyttäjien hallussaan pitämää sisältöä, mutta myös tämä määrä on voimakkaassa kasvussa. Osaltaan tämä kasvu johtuu käyttäjille suunnattujen digitaalista tietosisältöä tuottamaan kykenevien laitteiden määrän kiihtyvästä kasvusta. Toisaalta laitteiden tiedonsäilömiskapasiteetti on jo nyt noussut huomattavan suureksi, ja jatkaa edelleen tasaisesti kasvuaan. Tässä diplomityössä on toteutettu VisualREST–niminen sisällönhallintajärjestelmä. Keskeisimpänä tutkimusongelmana oli, miten hajautetussa ja heterogeenisessä ympäristössä sijaitsevaa sisältöä voidaan hallita? Lisäksi tutkittiin mitä teknologioita tämänkaltaiseen ympäristöön suunnatun sisällönhallintajärjestelmän toteuttamisessa voidaan käyttää. Tutkimusongelmien ratkaisemiseksi keskityttiin ensin sisällönhallintaan liittyvien ominaisuuksien määrittämiseen. Tutustumalla alan kirjallisuuteen, sekä sisällönhallinnan tutkimukseen onnistuttiin määrittämään sisällönhallintaan liittyvät keskeisimmät ominaisuudet. Kaikkien ominaisuuksien huomattiin osaltaan pyrkivän parantamaan sisällön saatavuutta, jota voidaankin perustellusti pitää sisällönhallintajärjestelmän keskeisimpänä tavoitteena. Ominaisuuksien kartoittamisen yhteydessä pyrittiin nostamaan esiin sisällönhallintaan liittyviä ongelmia, ja näihin ongelmiin on työn toteutuksen kuvauksen sekä arvioinnin yhteydessä pyritty ottamaan kantaa. Tutkimusongelmaan liittyvän heterogeenisen hajautetun ympäristön vaikutuksia sisällönhallintajärjestelmään on myös pyritty tuomaan esiin. Alusta alkaen on ollut selvää, että sisällönhallintajärjestelmän toteuttaminen tämänkaltaiseen ympäristöön tulee muodostamaan hajautetun järjestelmän. Tästä johtuen työn alkupuolella tutustuttiinkin hajautettuun järjestelmään teknologiana. Hajautettu järjestelmä pyrkii osaltaan kätkemään taustalla toimivan järjestelmän fyysisen rakenteen yhtenäisen rajapinnan avulla. Tämänkaltaisen abstrahoinnin katsottiin sopivan hyvin sisällönhallintajärjestelmään käyttäjille tarjottavan helppokäyttöisen rajapinnan toteuttamiseen. Toisaalta todettiin myös, että tämänkaltainen abstrahointi on erit- 6. Yhteenveto 75 täin tyyppillinen pilvilaskennan ominaisuus. VisualREST–järjestelmän katsottiinkin muodostavan ylläpitämistään käyttäjien laitteista ja niiden sisällöstä eräänlaisen sisältöpilven, jonka taustalla olevat monimutkaiset prosessit järjestelmä pyrkii käyttäjiltä abstrahoimaan. Tyypillisistä pilvipalveluista poiketen, VisualREST ei toimintafilosofiansa vuoksi varastoi sisällön essentiaa keskitetysti yhteen paikkaan, vaan sen sijaan sisällön essentia pyritään pitämään talletettuna sen tuottaneessa laitteessa. REST–suunnitteluperiaatteet ovat osoittautuneet erittäin toimivaksi tavaksi suunnitella ja toteuttaa helppokäyttöinen ja yhtenäinen rajapinta sisällönhallintajärjestelmään. Määrittämällä sisällönhallintaan liittyvät käsitteet resursseiksi, voidaan niille tarjota yhtenäinen rajapinta ja selkeät yksilölliset ositteet, joiden avulla näihin resursseihin voidaan kohdistaa CRUD–operaatioiden mukaisia toimenpiteitä. REST–suunnitteluperiaatteiden noudattamisessa ilmeni kuitenkin joitain pieniä ristiriitaisuuksia, joiden ratkaisemiseksi annettiin ehdotuksia. Sisällöhallintaan liittyvien ominaisuuksien täyttymistä ja toteutus teknologioiden soveltumista tarkoituksiinsa arvioitiin erillisessä luvussaan työn lopussa. VisualREST– järjestelmän voidaan tämän arvioinnin pohjalta todeta toteuttvan sisällönhallintaan liittyvät ominaisuudet hyvin. Esille nousseista ongelmista tärkeimmät liittyivät sisällön saatavuuteen, ja näiden ongelmien pohjalta sisällön saatavuuden todettiin olevan hyvin moniulotteinen ongelma. Teknologioiden katsottiin yleisesti soveltuvan tarkoituksiinsa hyvin. Suurimmat esille nousseet ongelmat liittyivät tietosäiliöohjelman käyttämän Git–versionhallinnan toteutuksen puuttumiseen useimmilta mobiilialustoilta. Toisaalta todettiin, ettei Git–versionhallinnan käyttäminen ole pakollista, sillä versiointi on kohtuullisella vaivannäöllä täysin mahdollista toteuttaa vastaavia periaatteita noudattaen mihin tahansa ympäristöön. Esille tuotiin myös ajatus valmiin versioinnin toteuttavan kirjaston tarjoamiseksi käytetyimmille mobiilialustoille. Työn lopussa esitettiin joitain keskeisimpiä VisualREST–järjestelmään suunniteltuja jatkokehitysajatuksia. Osaltaan näiden jatkokehitysajatusten toteuttamista on jo ehditty aloittamaan. Lisäksi tämän työn arviointi osuudessa esille nousseet parannus- ja korjausehdotukset tullaan toteuttamaan lähitulevaisuudessa. Järjestelmän kehittäminen on toistaiseksi ollut varsin aktiivista, ja uusia ominaisuuksia järjestelmään kaavaillaan toistuvasti. Mukaan kehitysprojektiin on myös tullut jatkuvasti uusia osapuolia, jotka ovat toteuttamassa erilaisia asiakas- ja tietosäiliöohjelmia VisualREST–järjestelmään, sekä käyttävät järjestelmää tutkimusalustana tehdessään sisällönhallintaan liittyvää tutkimusta. 76 LÄHTEET [1] Ancienne Route A, Editeur Responsable, P. A. Laven, and M. R. Meyer. EBU / SMPTE Task Force for Harmonized Standards for the Exchange of Programme Material as Bitstreams, 1998. [2] Amazon Simple Storage Service API–dokumentaatio. http://docs.amazonwebservices.com/AmazonS3/latest/. [viitattu 07.12.2010]. [3] Amazon Web Services kotisivu. http://aws.amazon.com/. [viitattu 07.12.2010]. [4] Apache HTTP Server kotisivu. http://httpd.apache.org/. [viitattu 22.11.2010]. [5] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. A view of cloud computing. Commun. ACM, 53:50–58, April 2010. [6] Tim Berners-Lee, Roy Thomas Fielding, and Larry Masinter. Uniform resource identifier (uri): Generic syntax. Internet Draft draft-fielding-uri-rfc2396bis-07, September 2004. [viitattu 11.10.2010]. [7] Paolo Bolettieri, Fabrizio Falchi, Claudio Gennaro, and Fausto Rabitti. Automatic metadata extraction and indexing for reusing e-learning multimedia objects. In Workshop on multimedia information retrieval on The many faces of multimedia semantics, MS ’07, pages 21–28, New York, NY, USA, 2007. ACM. [8] C. D. Cranor, R. Ethington, A. Sehgal, D. Shur, C. Sreenan, and J. E. van der Merwe. Design and implementation of a distributed content management system. In Proceedings of the 13th international workshop on Network and operating systems support for digital audio and video, NOSSDAV ’03, pages 4–11, New York, NY, USA, 2003. ACM. [9] Stentiford F. Curtis K., Foster W. P. Metadata – the key to content management services. In Proceedings of the Meta-Data’99, The Third IEEE Meta-Data Conference, Bethesa, Maryland, USA, 1999. [10] ejabberd Community site kotisivu. http://www.process-one.net/en/ejabberd/. [viitattu 07.11.2010]. LÄHTEET 77 [11] Hakan Erdogmus. Cloud computing: Does nirvana hide behind the nebula? In IEEE Software, volume 26, pages 4–6, Los Alamitos, CA, USA, 2009. IEEE Computer Society. [12] Face Recognition kotisivu. http://www.face-rec.org/. [viitattu 07.11.2010]. [13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1. W3C/MIT, June 1999. [14] Roy Thomas Fielding. REST: Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000. [15] Git - Fast Version Control System kotisivu. http://git-scm.com/. [viitattu 19.11.2010]. [16] Git Community Book. http://book.git-scm.com/book.pdf. [viitattu 11.10.2010]. [17] Grit API–dokumentaatio. http://grit.rubyforge.org/. [viitattu 27.11.2010]. [18] Ilkka Haikala and Jukka Märijärvi. Ohjelmistotuotanto. Talentum, Helsinki, Suomi, 11. edition, 2006. [19] IDC. The digital universe decade – are you ready? http://idcdocserv.com/925. [viitattu 15.12.2010]. [20] Internet Engineering Task Force. RFC 791 Internet Protocol - DARPA Inernet Programm, Protocol Specification, September 1981. [21] Jabber Software Foundation. RFC 3920 - Extensible Messaging and Presence Protocol (XMPP), October 2004. [22] Andreas Mauthe and Peter Thomas. Professional content management systems: handling digital media assets. John Wiley & Sons, West Sussex, England, 2004. [23] Peter Millard, Peter Saint-Andre, and Ralph Meijer. XMPP Standards Foundation. XEP-0060: Publish-Subscribe. http://xmpp.org/extensions/xep-0060.html. [24] MySQL kotisivu. http://www.mysql.com/. [viitattu 07.12.2010]. LÄHTEET 78 [25] NewBay Software, Google. RFC 5023 – The Atom Publishing Protocol, October 2007. [26] Phusion Passenger kotisivu. http://www.modrails.com/. [viitattu 12.11.2010]. [27] Leonard Richardson and Sam Ruby. RESTful Web Services. O’Reilly, Sebastopol, CA, US, 2007. [28] Ruby on Rails kotisivu. http://rubyonrails.org/. [viitattu 09.10.2010]. [29] Ruby Programming Language kotisivu. http://www.ruby-lang.org/. [viitattu 09.10.2010]. [30] Peter Saint-Andre, Kevin Smith, and Remko TronCon. XMPP: The Definitive Guide: Building Real-Time Applications with Jabber Technologies. O’Reilly Media, Sebastopol, CA, US, 1 edition, 2009. [31] Antonietta Spedalieri, Albert Sinfreu, Giuseppe Sisto, Pablo Cesar, Ishan Vaishnavi, and Dario Melpignano. Multimedia content management support in next generation service platforms. In Proceedings of the 3rd international conference on Mobile multimedia communications, MobiMedia ’07, pages 14:1–14:7, ICST, Brussels, Belgium, Belgium, 2007. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering). [32] Subversion kotisivu. http://subversion.apache.org/. [viitattu 12.12.2010]. [33] Andrew S. Tanenbaum and Maarten van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, Upper Saddle River, NJ, 2. edition, 2007. [34] The Google Geocoding API–dokumentaatio. http://code.google.com/intl/fi-FI/apis/maps/documentation/geocoding/. [viitattu 07.12.2010]. [35] Dave Thomas, David Hansson, Leon Breedt, Mike Clark, Thomas Fuchs, and Anreas Schwarz. Agile Web Development with Rails, Third Edition. Pragmatic Bookshelf, Dallas, Texas, US, 3rd edition, 2009. [36] YAML kotisivu. http://www.yaml.org/. [viitattu 10.11.2010]. 79 A. ESIMERKKI METATIETOLISTA Tiedostolistan muutokset annetaan contains–nimisessä parametrissa. Seuraava metatietolista sisältää yhden päivitetyn ja yhden luodun sisällön initiaalimetatiedot. contains= --/1.jpg: name: 1.jpg filedate: 12:21:53 2010-10-29 size: 20662 filetype: image/jpeg path: / blob_hash: cf9912eddafaa932e9e172ae79eec38b168435c5 status: updated /kansio/2.jpg: name: 2.jpg filedate: 12:21:53 2010-10-29 size: 20662 filetype: image/jpeg path: /kansio/ blob\_hash: gf1112ettauuu621r8e334xx66ytc38b555454ff status: created 80 B. HAKUTULOSTEN ATOM–SYÖTE <?xml version="1.0" encoding="UTF-8"?> <feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom"> <id> tag:visualrest.cs.tut.fi,2005:/user/testuser/device/Winter_N900/files </id> <link type="text/html" href="http://visualrest.cs.tut.fi" rel="alternate"/> <link type="application/atom+xml" href="http://visualrest.cs.tut.fi/user/testuser /device/Winter_N900/files.atom" rel="self"/> <title>Files of testuser, Device: Winter_N900</title> <updated>2010-11-18T10:07:37+00:00</updated> <entry> <id> http://visualrest.cs.tut.fi/user/testuser /device/Winter_N900/files/s18.jpg </id> <published>2010-11-18T14:15:13+00:00</published> <updated>2010-11-18T14:15:14+00:00</updated> <link type="text/html" href="http://visualrest.cs.tut.fi/user/testuser /device/Winter_N900/files/s18.jpg" rel="alternate"/> <title>s18.jpg</title> <thumbnail> http://visualrest.cs.tut.fi/thumbnails /83/ba2d5475c27c484a8f9d5868ed1807e7c9415e71.png </thumbnail> <file_version>0</file_version> <filepath>/</filepath> <filetype>image/jpeg</filetype> <filesize>72474</filesize> B. Hakutulosten Atom–syöte 81 <file_device>Winter_N900</file_device> <file_versionlist_url> http://visualrest.cs.tut.fi/user/testuser /device/Winter_N900/fileversions/s18.jpg?format=atom </file_versionlist_url> <version_hash> ba2d5475c27c484a8f9d5868ed1807e7c9415e71 </version_hash> <location> <longitude>0.0</longitude> <latitude>0.0</latitude> </location> <file_status>cached</file_status> <device_status>offline</device_status> <content type="html"><table><tr><td valign="top "><img src=" /thumbnails/83/ba2d5475c27c484a8f9d5868ed1807e7c9415e71.png " alt="s18.jpg" /></td><td valign="top "><b>s18.jpg</b> - version: 0<br/> type: image/jpeg<br/>size: 72474 B<br/><b> Device:</b> Winter_N900<br/><b> User:</b> testuser<br/><a href=" /user/testuser/device/Winter_N900/fileversions/s18.jpg?format=atom ">Version list</a></td></tr></table> </content> <author> <name>testuser</name> </author> </entry> </feed>
© Copyright 2024