1. No category

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">&lt;table&gt;&lt;tr&gt;&lt;td valign=&quot;top
&quot;&gt;&lt;img src=&quot;
/thumbnails/83/ba2d5475c27c484a8f9d5868ed1807e7c9415e71.png
&quot; alt=&quot;s18.jpg&quot; /&gt;&lt;/td&gt;&lt;td valign=&quot;top
&quot;&gt;&lt;b&gt;s18.jpg&lt;/b&gt; - version: 0&lt;br/&gt;
type: image/jpeg&lt;br/&gt;size: 72474 B&lt;br/&gt;&lt;b&gt;
Device:&lt;/b&gt; Winter_N900&lt;br/&gt;&lt;b&gt;
User:&lt;/b&gt; testuser&lt;br/&gt;&lt;a href=&quot;
/user/testuser/device/Winter_N900/fileversions/s18.jpg?format=atom
&quot;&gt;Version list&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;
</content>
<author>
<name>testuser</name>
</author>
</entry>
</feed>