Tämä materiaali on lisensoitu Creative Commons BY-NC-SA-lisenssillä, joten voit käyttää ja levittää sitä vapaasti, kunhan alkuperäisten tekijöiden nimiä ei poisteta. Jos teet muutoksia materiaaliin ja haluat levittää muunneltua versiota, se täytyy lisensoida samanlaisella vapaalla lisenssillä. Materiaalien käyttö kaupalliseen tarkoitukseen on ilman erillistä lupaa kielletty.

Lukijalle

Tämä materiaali on tarkoitettu Helsingin yliopiston tietojenkäsittelytieteen laitoksen syksyn 2012 kurssille web-palvelinohjelmointi. Materiaaliin on vaikuttanut vahvasti Helsingin yliopistossa keväällä 2012 järjestetty kurssi web-sovellusohjelmointi, sekä siitä saatu palaute. Materiaalin kirjoittaja on Arto Vihavainen ja sen syntyyn ovat vaikuttaneet useat tahot, joista tärkeimmät ovat Matti Luukkainen ja Mikael Nousiainen. Syksyn kurssimateriaaliin liittyvistä ehdotuksista ja ajatuksista tulee kiittää muun muassa Kasper Hirvikoskea ja Hansi Keijosta. Erityinen kiitos kuuluu myös Martin Pärtelille, joka on mahdollistanut TMC:n käytön kurssilla.

Web-sovelluksista yleisesti

Web-sovellukset koostuvat yleisesti ottaen kahdesta: palvelinpuolesta ja selainpuolesta. Palvelinpuoli hoitaa palvelimella tapahtuvan toiminnan, esimerkiksi tietokannan muokkauksen ja erilaiset laskentaoperaatiot. Selaimessa taas näytetään käyttäjälle data ja lähetetään tietoa palvelimelle, joka taas palauttaa käyttäjälle selaimessa näytettävää tietoa.

Käytännössä web-sovellukset koostuvat datasta jolle on määritelty ilmaisumuoto. Selainohjelmointiin ja käyttöliittymäsuunniteluun keskityttäessä painotetaan ulkoasun ja sisällön erotusta toisistaan CSS:n avulla, sekä luodaan interaktiivista toiminnallisuutta Javascriptiin ja nykyaikaisiin web-teknologioihin tukeutuen. HTML5 tukee videoiden näyttämistä, musiikin soittamista ja piirtämistä, ja WebGL taas laajentaa Canvas-toiminnallisuutta tuoden 3D-tuen ja -kiihdytyksen selaimiin.

Web-sovellukset eivät sisällä sivuja samalla tavalla kuin perinteiset web-sivut sisältävät. Vaikka web-sovelluksessa voi ulkopuolisen silmin olla esimerkiksi 5 sivua, uuden sisällön lisääminen tietokantaan tai vastaavaan tietoa tallentavaan järjestelmään mahdollistaa sivumäärän kasvattamisen ilman muutoksia lähdekoodissa. Käyttäjälle tarjotut hakutoiminnallisuudet mahdollistavat lähes rajattoman määrän sivuja; kukaan ei kirjoittaisi näitä käsin.

Pieni määrä sivupohjia (ns. templateja) ja palvelinpuolen sovelluslogiikkaa mahdollistaa sivujen luomisen lennosta suoraan web-osoitetta tai lomakkeella lähettyä dataa käyttäen.

Keskivertokäyttäjälle web-sovellukset näyttävät samalta kuin perinteiset web-sivut. Yksinkertaisen web-sovelluksen lähdekoodia katsottaessa voi olla mahdotonta päätellä ovatko sivut luotu dynaamisesti vai kirjoitettu jotain editoria käyttäen (tai käsin). Web-osoitteesta voi yrittää päätellä jotain (.html, ...), mutta oikeasti web-osoitteiden päätteet ovat vain osa osoitetta: .html -päätteisellä sivulla voi hyvin olla web-sovellus taustalla. Web-sovellus näyttää usein sovellukselta vain niille jotka muokkaavat sovellukseen liittyvää dataa. Sekä sovelluksen käyttö että datan muokkaus tapahtuu yleensä HTML-käyttöliittymää käyttäen. Web-sovellusta voi hallita myös työpöytäsovelluksella, joka muokkaa web-sovelluksen käyttämää dataa.

Javascript (käytännössä AJAX, Asynchronous JavaScript and XML) mahdollistaa sivujen sisällön uudelleen lataamisen ja päivittämisen ilman että käyttäjän tarvitsee tehdä erillisiä pyyntöjä tai kirjoittaa uutta osoitetta selaimen osoitepalkkiin. AJAX mahdollistaa muutosten tekemisen taustalla -- ilman että käyttäjän tarvitsee siirtyä sivulta toiselle -- joka pienentää web-sovellusten ja työpöytäsovellusten välistä eroa.

Työpöytäsovellukset tarjoavat enemmän interaktiivisuutta ja nopeutta web-sovelluksiin verraten. Web-sovellukset mahdollistavat saumattomat ohjelmistojen päivitykset, todellisen tiedot ja dokumenttien jakamisen ja kevyet käyttöliittymät.

Elämme jatkuvaa muutosta. Muutoksesta riippumatta web-sovellukset ovat järjestelmiä, jotka sisältävät dataa. Dataa voi käsitellä web-sivujen kautta ja muita rajapintoja käyttäen. Google tarjoaa Google Documents -palvelua ilmaiseksi kaikkien käyttöön, mahdollistaen käyttäjälle pääsyn dokumentteihin mistä tahansa. Microsoft tarjoaa kaikille ilmaista sähköpostipalvelua, verkko on täynnä ilmaisia webissä toimivia pelejä...

Tälläkin hetkellä ohjelmistoyhtiöt ympäri maailmaa kehittävät uusia innovaatioita, jotka tulevat tulevaisuudessa syrjäyttämään perinteiset työpöytäsovellukset.

Web-sovellusten kehittäminen

Sovellusten arkkitehtuurista perinteisesti puhuttaessa puhutaan talojen tai rakennusten rakentamisesta. Taloa suunnitellessa arkkitehdillä on selkeä tehtävä ja tavoitteet: kerää vaatimukset, tutki vaihtoehtoja ja luo pohjapiirrustus. Pohjapiirrustusta seuraten erillinen joukko työntekijöitä -- rakennusmiehet -- rakentaa konkreettisen rakennuksen.

Ohjelmistoja suunniteltaessa arkkitehti osallistuu sekä ohjelmiston suunnitteluun että kehitykseen, eli konkreettiseen rakentamiseen. Suunnittelussa hän aloittaa perustarpeista ja muutamasta huoneesta, jonka jälkeen jo muutama ihminen alkaa käyttämään rakennusta. Kun alkuperäinen suunnitelma on lähes valmis, rakennukseen muuttaa lisää ihmisiä. Nämä tarvitsevat lisää rakennukselta: uusia huoneita, pesulan, diskon ja luonnollisesti oleskelutilan, jossa on tilaa biljardipöydälle. Arkkitehti soveltaa alkuperäistä suunnitelmaansa mukauttamaan uudet ihmiset ja kehitystyö jatkuu.

Toimintoja kehitettäessä alkuperäiset asukkaat eivät muuta pois, vaan valittavat jatkuvasta rakennusmelusta. Yhä enemmän ihmisiä muuttaa rakennukseen ja rakennukselta vaaditaan taas lisää (mm. cartingrata ja curlinghalli).

Hyvän arkkitehtuurisuunnittelun perusta on mahdollisuuksien huomiointi. Huomioinnilla ei tarkoiteta sitä, että rakennetaan heti aluksi iso järjestelmä -- käytännössä järjestelmän valmistuessa sille ei olisi käyttäjiä sillä kaikki olisivat siirtyneet toiseen aiemmin tarpeellisia ominaisuuksia tarjonneeseen järjestelmään. Jos alkuperäinen suunnitelma tekee järjestelmän laajentamisesta vaikeaa, käyttäjät saattavat vaihtaa palvelua hitauden takia.

Ohjelmistokehityksessä saadaan käytännössä hyvin harvoin ensimmäisellä yrityksellä rakennettua toimiva ja tyydyttävä ratkaisu. Jokaista ohjelmistoa joudutaan laajentamaan, rajaamaan ja refaktoroimaan. Asiakkaalla tai asiakkailla on käytännössä aina uusia toivomuksia ohjelmiston elinkaaren varrella.

Arkkitehtuurin tulee mahdollistaa sopivan kokoisesta palasta aloittaminen sekä rakennettavan sovelluksen laajentaminen, myös toisten kehittäjien toimesta, mahdollisimman kevyesti. Hyvin harvat ohjelmistot ovat vain yhden ihmisen käsialaa, avoimeen lähdekoodiin ja online-versionhallintatyökaluihin (esim github) perustuvat projektit saavat ihmiset eri puolilta maailmaa tekemään työtä yhteisen mielenkiinnon parissa. Ryhmätyössä sovittujen käytänteiden (esim. nimeämiskäytänteet, versionhallinta, testaus, dokumentointi ym.) olemassaolo on oleellista. Kommunikointi niin koodin kautta kuin muita väyliä käyttäen on oleellista -- muuttujanimet a, b, c, foo ja bar aiheuttavat lukijalle lähinnä kylmiä väreitä.

Web-sovelluskehityksessä nopeasta kehityssyklistä on paljon hyötyä. Työkaluja valittaessa tarkoituksena on välttää nurkkaan ajautumista: työkaluista tulee pystyä myös pääsemään eroon. On paljon hyödyllisempää miettiä asiaa päivä ja käyttää muutama päivä prototyypin tekemiseen, koska prototyyppiä voidaan parantaa kuukausia, kuin miettiä kuukausi ja sitouttaa itsensä kuukauden aikana luotuun suunnitelmaan. Mitä nopeammin toiminnallisuutta on olemassa, sitä nopeammin siitä saa palautetta. Mitä vähemmän käytämme aikaa yksittäisen toiminnallisuuden toteuttamiseen -- KISS -- sitä helpommin siitä voi tarpeen vaatiessa hankkiutua eroon.

Kurssilla käytettävät työvälineet

Työkalut ovat oleellinen osa ohjelmistoryhmän yhteisten pelisääntöjä. Tällä kurssilla käytämme ohjelmointiympäristönä NetBeansia, ja ohjelmistoprojektien hallintaan Maven-projektinhallintatyökalua. Nykyaikaisestakin ohjelmistokehityksestä osa tapahtuu terminaalissa eli komentotulkissa, joten käytämme myös sitä kurssin aikana.

Oletamme että käytössäsi on Google Chrome tai vastaavat web-sovelluskehittäjän apuvälineet sisältävä www-selain.

Ohjelmistoprojektien hallinta

Ohjelmistokehittäjän arjesta huomattava osa menee projekteihin liittyviin tehtäviin kuten ylläpitoon. Jokaisessa ohjelmistoprojektissa on erilaisia lähdekoodiin liittyviä tavoitteita, joita kehittäjien tulee pystyä toteuttamaan. Lähdekoodia tulee pystyä paketoimaan tuotantoon siirettäväksi paketiksi (esim -.jar ja -.war -tiedostot), lähdekoodiin liittyviä testejä tulee pystyä ajamaan erillisellä palvelimella ja lähdekoodista tulee pystyä generoimaan erilaisia raportteja sekä luonnollisesti dokumentaatiota.

Työkalut kuten Apache Ant auttavat projektiin liittyvän lähdekoodin hallinnoinnissa ja kääntämisessä. Ant on käytännössä 2000-luvun alun vastine perinteisille Makefile-tiedostoille. Nykyaikaisempi Apache Maven auttaa käännösprosessin lisäksi projektiin liittyvien kirjastoriippuvuuksien automaattisessa hallinnassa.

Maven

Apache Maven on projektinhallintatyökalu, jota voi käyttää ohjelmakoodikäännösten automatisoinnin lisäksi lähes koko projektin elinkaaren hallintaan uuden projektin aloittamisesta lähtien. Maven tarjoaa ohjelmiston elinkaaren hallintaan joukon valmiiksi konfiguroituja vaiheita (phase), joita voidaan suorittaa komentoriviltä. Tyypillisiä jo olemassaolevia vaiheita ovat test, joka suorittaa projektiin liittyvät testit, sekä package, joka paketoi lähdekoodin projektityypistä riippuen sopivaan pakettiin. Oikeastaan maven on sovelluskehys plugin-komponenttien suoritukseen, yksinkertaisimmatkin tehtävät on tehty pluginien avulla.

Jokaisella Maven-projektilla on elinkaari, joka sisältää vaiheet lähtien projektin validoinnista, kääntämisestä ja testaamisesta aina tuotantoon siirtämiseen asti. Tarkempi listaus projektin erilaisista vaiheista löytyy Mavenin dokumentaatiosta. Kukin vaihe koostuu yhdestä tai useammasta projektiin liittyvästä tavoitteesta (goal), jotka suoritetaan vaiheen sisällä. Vaiheet riippuvat myös edellisistä vaiheista, esimerkiksi vaihetta test suoritettaessa Maven suorittaa ensin projektin validoinnin ja kääntämisen.

Mavenin pluginarkkitehtuuri mahdollistaa hyvin monipuolisen toiminnallisuuden. Esimerkiksi raportointiin ja staattiseen koodianalyysiin löytyy omat pluginit, samoin kuin web-palvelimen käynnistämiselle projektin testausta varten. Mavenin plugineista löytyy (ei kattava) lista osoitteessa http://maven.apache.org/plugins/index.html.

Maven automatisoi uusien projektien luomisen archetype-pluginin avulla, jonka avulla käyttäjät voivat tarjota valmiita projektirunkoja toisilleen. Projektirungot toimivat pohjina uusille samaa arkkitehtuuria käyttäville projekteille. Runkojen avulla ohjelmistokehittäjät voivat jakaa hyviksi todettuja käytänteitä, ja ne helpottavat myös organisaatioiden sisällä tapahtuvaa erilaisiin projektityyppeihin liittyvien arkkitehtuurien ylläpitoa.

Ohjelmistokehittäjän näkökulmasta yksi tärkeimmistä ominaisuuksista on riippuvuuksien automaattinen lataaminen. Mavenin avulla projektiin voi konfiguroida kirjastoriippuvuuksia, esimerkiksi riippuvuudet yksikkötestauskirjastoihin ja web-sovelluskehyksen kirjastoihin. Maven lataa riippuvuudet automaattisesti, jolloin kirjastoja ei tarvitse pitää esimerkiksi versionhallinnassa.

Webin peruskomponentit

"I just had to take the hypertext idea and connect it to the TCP and DNS ideas and – ta-da! – the World Wide Web." -- Tim Berners-Lee

Kolme internetin oleellisinta osaa ovat tapa yksilöidä palveluja ja palvelujen tarjoamia resursseja verkosta (DNS, Domain Name Services ja URI, Uniform Resource Identifier), protokolla viestien lähetykseen verkon yli (HTTP, HyperText Transfer Protocol) ja yhteinen dokumenttien esityskieli (HTML, HyperText Markup Language).

URI ja DNS

"The most important thing that was new was the idea of URI-or URL, that any piece of information anywhere should have an identifier, which will allow you to get hold of it." -- Tim Berners-Lee

Verkossa sijaitseva sivusto tunnistetaan sille annetun yksilöivän osoitteen perusteella. Osoite (URI eli Uniform Resource Identifier terminä käyttöön jäänyt URL Uniform Resource Locator) koostuu resurssin nimestä ja sijainnista, joiden perusteella kysyttyyn palvelimeen ja resurssiin voidaan muodostaa yhteys.

Periaatteessa palvelimelle tehtävää kyselyä voidaan ajatella metodikutsuna, jonka tulee palauttaa arvo tai heittää poikkeus.

Käytännössä kun käyttäjä kirjoittaa web-selaimen osoitekenttään URIn ja painaa enteriä, web-selain lähtee tekemään kyselyä annettuun osoitteeseen. Koska tekstimuotoiset osoitteet ovat käytännössä vain ihmisiä varten, tulee selaimen ensiksi kääntää haluttu osoite, esimerkiksi www.mooc.fi, IP-osoitteeksi. Jos IP-osoite on jo tiedossa esimerkiksi aiemmin osoitteeseen tehdyn kyselyjen takia, selain voi ottaa yhteyden IP-osoitteeseen. Jos taas IP-osoite ei ole tiedossa, tulee selaimen ensin tehdä kysely DNS-palvelimelle (Domain Name System), jonka tehtävänä on muuntaa tekstuaaliset osoitteet IP-osoitteiksi (esim. http://www.cs.helsinki.fi -> 128.214.166.78).

Ilman DNS-palvelimia ihmisten tulisi muistaa IP-osoitteet ulkoa, joka käytännössä tarkoittaisi ettei nykyinen internet toimisi.

IP-osoitteet yksilöivät tietokoneet, ja mahdollistavat koneiden löytämisen verkon yli. Käytännössä yhteys IP-osoitteen määrittelemään koneeseen avataan sovellustason HTTP-protokollan avulla kuljetustason TCP-protokollan yli. TCP-protokollan tehtävänä on varmistaa, että viestit pääsevät perille. Lisää tietoa konkreettisesta tietoliikenteestä kurssilla Tietoliikenteen perusteet.

Kun palvelin vastaanottaa tiettyyn resurssiin liittyvän pyynnön, palauttaa se vastauksen kyselijälle. Kun selain saa vastauksen, tarkistaa se vastaukseen liittyvän statuskoodin ja siihen liittyvät tiedot. Jos vastauksen saa tallettaa välimuistiin, tallennetaan se tulevaisuutta varten. Tämän jälkeen selain päättelee, mitä vastauksella tehdään, ja esimerkiksi renderöi vastaukseen liittyvän web-sivun käyttäjälle.

Käytännössä URIt näyttävät seuraavilta:

protokolla://isäntäkone[:portti]/polku/../[kohdedokumentti][?kyselyparametrit][#ankkuri]

• protokolla: kyselyssä käytettävä protokolla, esimerkiksi http tai ftp.
• isäntäkone: kone tai palvelin johon luodaan yhteys. Voi olla joko IP-osoite tai tekstuaalinen kuvaus.
• portti: portti isäntäkoneella johon yhteys luodaan. HTTP-palvelimien oletusportti on 80. Jos palvelin käyttää eri porttinumeroa kuin 80, tulee se merkitä osoitteeseen. Portti käytännössä määrittelee prosessin, johon yritetään ottaa yhteyttä.
• polku: periaatteessa polku resurssiin palvelimella. Käytännössä (nykyään) palvelun osoite, johon palvelin osaa osoittaa. Usein palvelut toimivat erillisessä koneessa sisäverkossa, ja ulkoverkkoon näkyvä kone vain toimii ohjaajana eli proxynä oikeaan palveluun.
• kohdedokumentti: haettava resurssi, jos kohdedokumenttia ei ole määritelty palvelin päättelee oletusdokumentin. Usein index.html
• kyselyparametrit: koostuu avain-arvo -pareista, joiden avulla palvelimelle pystyy toteuttamaan lisätoiminnallisuutta. Kuhunkin avaimeen liittyvä arvo esitetään = -merkillä, avain-arvo -parit erotetaan toisistaan &-merkillä.
• ankkuri: kertoo mihin kohtaan dokumentissa tulee mennä.

HTTP

HTTP (HyperText Transfer Protocol) on TCP/IP -protokollapinon sovellustason protokolla. Web-palvelimet ja selaimet keskustelevat HTTP-protokollaa käyttäen. HTTP-protokolla perustuu asiakas-palvelin malliin, jossa jokaista pyyntöä kohden on yksi vastaus (request-response paradigm). Käytännössä HTTP-asiakasohjelma (jatkossa selain) lähettää HTTP-viestin HTTP-palvelimelle (jatkossa palvelin), joka palauttaa HTTP-vastauksen. HTTP-protokollan versio 1.1 on määritelty RFC 2616-spesifikaatiossa.

Asiakas-palvelin malli

Asiakas-palvelin -mallissa (Client-Server model) asiakkaat käyttävät palvelimen tarjoamia palveluja. Kommunikointi asiakkaan ja palvelimen välillä tapahtuu usein verkon yli siten, että asiakasohjelmisto ja palvelinohjelmisto sijaitsevat erillisissä fyysisissä sijainneissa (eri tietokoneilla). Palvelinohjelmisto tarjoaa yhden tai useamman palvelun, joita asiakasohjelmisto käyttää.

Käytännössä asiakasohjelmisto tarjoaa käyttöliittymän ohjelmiston loppukäyttäjälle. Asiakasohjelmiston käyttäjän ei tarvitse tietää, että kaikki käytetty tieto ei ole hänen koneella. Käyttäjän tehdessä toiminnon asiakasohjelmisto pyytää tarpeen vaatiessa palvelimelta käyttäjän tarpeeseen liittyvää lisätietoa. Tyypillistä mallille on se, että palvelin tarjoaa vain asiakkaan pyytämät tiedot. Tällöin verkossa liikkuvan tiedon määrä pysyy vähäisenä.

Asiakas-palvelin -malli mahdollistaa hajautetut ohjelmistot: asiakasohjelmistoa käyttävät loppukäyttäjät voivat sijaita eri puolilla maapalloa palvelinohjelmiston sijaitessa tietyssä paikassa.

Haasteena perinteisessä asiakas-palvelin mallissa on se, että palvelin sijaitsee yleensä tietyssä keskitetyssä sijainnissa. Keskitetyillä palveluilla on mahdollisuus ylikuormittua asiakasmäärän kasvaessa. Kapasiteettia rajoittavat muunmuassa palvelimen fyysinen kapasiteetti (rauta), palvelimeen yhteydessä olevan verkon laatu ja nopeus, sekä tarjotun palvelun tyyppi. Esimerkiksi tietokantatransaktiota vaativat pyynnöt vievät huomattavasti enemmän aikaa kuin yksinkertaiset lukuoperaatiot. Asiakas-palvelin mallissa tuottaa haasteita myös vikasietoisuus, miten toimia jos palvelinkoneesta hajoaa esimerkiksi kovalevy?

HTTP-viestin rakenne: palvelimelle lähetettävä kysely

HTTP-protokollan yli lähetettävät viestit ovat tekstimuotoisia. Viestit koostuvat riveistä jotka muodostavat otsakkeen, sekä riveistä jotka muodostavat viestin rungon. Viestin runkoa ei ole pakko olla olemassa. Viestin loppuminen ilmoitetaan kahdella peräkkäisellä rivinvaihdolla. Palvelimelle lähetettävän viestin, eli kyselyn, ensimmäisellä rivillä on pyyntötapa, halutun resurssin polku ja HTTP-protokollan versionumero.

PYYNTÖTAPA /POLKU_HALUTTUUN_RESURSSIIN HTTP/versio
otsake-1: arvo
otsake-2: arvo

valinnainen viestin runko

Pyyntötapa kertoo HTTP-protokollassa käytettävän pyynnön tavan (esim. GET tai POST), polku haluttuun resurssiin kertoo haettavan resurssin sijainnin palvelimella (esim. /index.html), ja HTTP-versio kertoo käytettävän version (esim. HTTP/1.0). Alla esimerkki hyvin yksinkertaisesta -- joskin yleisestä -- pyynnöstä. Huomaa että pyyntöä tehdessä yhteys palvelimeen on jo muodostettu, eli palvelimen osoitetta ei merkitä erikseen.

GET /index.html HTTP/1.0

Yksittäisen koneen dedikointi web-palvelimeksi jättää usein huomattavan osan koneen kapasiteetista käyttämättä. Nykyään yleisesti käytössä oleva HTTP/1.1 -protokolla mahdollistaa useamman palvelimen pitämisen samalla koneella virtuaalipalvelintekniikan avulla, jolloin yksittäiset palvelinkoneet voivat sisältää useita palvelimia. Käytännössä IP-osoitetta kuunteleva kone voi joko itsessään sisältää useita ohjelmistoilla emuloituja palvelimia, tai se voi toimia reitittimenä ja ohjata pyynnön tietylle esimerkiksi yrityksen sisäverkossa sijaitsevalle koneelle. Kun yksittäinen IP-osoite voi sisältää useampia palvelimia, pelkkä polku haluttuun resurssiin ei riitä oikean resurssin löytämiseen: resurssi voisi olla millä tahansa koneeseen liittyvällä virtuaalipalvelimella. HTTP/1.1 -protokollassa on pyynnöissä pakko olla mukana käytetyn palvelimen osoitteen kertova Host-otsake.

GET /index.html HTTP/1.1
Host: www.munpalvelin.net

HTTP-viestin rakenne: palvelimelta saapuva vastaus

Palvelimelle tehtyyn pyyntöön saadaan aina jonkinlainen vastaus. Jos tekstimuotoiseen osoitteeseen ei ole liitetty IP-osoitetta DNS-palvelimilla, selain ilmoittaa ettei palvelinta löydy. Jos palvelin löytyy, ja pyyntö saadaan tehtyä palvelimelle asti, tulee palvelimen myös vastata jollain tavalla.

Palvelimelta saatavan vastauksen sisältö on seuraavanlainen. Ensimmäisellä rivillä HTTP-protokollan versio, viestiin liittyvä statuskoodi, sekä statuskoodin selvennys. Tämän jälkeen on joukko otsakkeita, tyhjä rivi, ja mahdollinen vastausrunko. Vastausrunko ei ole pakollinen.

HTTP/versio statuskoodi selvennys
otsake-1: arvo
otsake-2: arvo

valinnainen vastauksen runko

Esimerkiksi:

HTTP/1.1 200 OK
Date: Sat, 07 Jan 2012 03:12:45 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 973
Connection: close
Content-Type: text/html;charset=UTF-8

.. runko ..

Statuskoodit

Statuskoodit (status code) kuvaavat palvelimella tapahtunutta toimintaa kolmella numerolla. Statuskoodien avulla palvelin kertoo mahdollisista ongelmista tai tarvittavista lisätoimenpiteistä. Yleisin statuskoodi on 200, joka kertoo kaiken onnistuneen oikein. HTTP/1.1 sisältää viisi kategoriaa vastausviesteihin.

• 1**: informaatioviestit (esim 100 "Continue")
• 2**: onnistuneet tapahtumat (esim 200 "OK")
• 3**: asiakasohjelmistolta tarvitaan lisätoimintoja (esim 301 "Moved Permanently")
• 4**: virhe pyynnössä tai erikoistilanne (esim 401 "Not Authorized" ja 404 "Not Found")
• 5**: virhe palvelimella (esim 500 "Internal Server Error")

Lisätietoja statuskoodeista osoitteissa http://httpcats.herokuapp.com.

HTTP-protokollan pyyntötavat

HTTP-protokolla määrittelee kahdeksan erillistä pyyntötapaa (Request method). Yleisimmin käytetyt ovat GET, POST ja HEAD, joiden lisäksi on olemassa PUT, DELETE, TRACE, OPTIONS ja CONNECT. Pyyntötavat määrittelevät rajoitteita ja suosituksia viestin rakenteeseen ja niiden prosessointiin palvelinpäässä. Esimerkiksi Java Servlet API (versio 2.5) sisältää seuraavan suosituksen GET-pyyntotapaan liittyen:

The GET method should be safe, that is, without any side effects for which users are held responsible. For example, most form queries have no side effects. If a client request is intended to change stored data, the request should use some other HTTP method.

The GET method should also be idempotent, meaning that it can be safely repeated. Sometimes making a method safe also makes it idempotent. For example, repeating queries is both safe and idempotent, but buying a product online or modifying data is neither safe nor idempotent.

Suomeksi yksinkertaistaen: GET-tyyppisten pyyntöjen ei pitäisi muuttaa palvelimella olevaa dataa.

GET

GET on yksinkertaisin pyyntötapa. Sitä käytetään esimerkiksi dokumenttien hakemiseen: kun kirjoitat osoitteen selaimen osoitekenttään ja painat enter, selain tekee GET-pyynnön. GET-pyynnöt eivät tarvitse otsaketietoja HTTP/1.1:n vaatiman Host-otsakkeen lisäksi. Mahdolliset kyselyparametrit lähetetään palvelimelle osana haettavaa osoitetta.

GET /lets/See?porkkana=1 HTTP/1.1
Host: t-avihavai.users.cs.helsinki.fi

POST

Käytännön ero POST- ja GET-kyselyn välillä on se, että POST-tyyppisillä pyynnoillä kyselyparametrit liitetään pyynnön runkoon. Rungon sisältö ja koko määritellään otsakeosiossa. POST-kyselyt mahdollistavat multimedian (kuvat, videot, musiikki, ...) lähettämisen palvelimelle.

POST /lets/See HTTP/1.1
Host: t-avihavai.users.cs.helsinki.fi
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

porkkana=1

HEAD ja otsakkeet

HEAD-kyselyt ovat samantyyppisiä GET-kyselyiden kanssa, mutta niillä pyydetään palvelimelta vain haettavaan dokumenttiin liittyviä otsaketietoja. Tämä mahdollistaa muunmuassa muutosten seurannan palvelimelta saatavan Last-modified-otsakkeen avulla, sekä palvelimen toiminnallisuuden testaamisen.

HEAD-kyselyä on perinteisesti käytetty välimuistitoiminnallisuuden toteuttamiseen, jolloin selaimen välimuistissa olevista dokumenteista on tehty ensiksi vain HEAD-kysely. Jos dokumentti ei ole muuttunut, eli otsake Last-modified sisältää tarpeeksi vanhan ajan, ei dokumenttiin liittyvää runkoa ole haettu.

Luodaan telnetillä yhteys palvelimeen www.cs.helsinki.fi ja kysytään otsaketietoja resurssiin /home/ liittyen. Käytämme HTTP:n versiota 1.1 (HTTP/1.1), joten lisäämme pyyntöön myös Host-otsakkeen.

$ telnet www.cs.helsinki.fi 80
Trying 128.214.166.78...
Connected to www.cs.helsinki.fi.
Escape character is '^]'.
HEAD /home/ HTTP/1.1
Host: www.cs.helsinki.fi 

Vastauksena saamme palvelimen vastausrivin jossa on HTTP-versio, statuskoodi ja selvennys. Seuraavilla riveillä on otsakkeita, jotka tarjoavat lisätietoa haettavasta dokumentista ja käytettävästä palvelimesta.

HTTP/1.1 200 OK
Date: Sat, 07 Jan 2012 07:13:49 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.11
Last-Modified: Sat, 07 Jan 2012 07:13:51 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

Vastauksesta huomataan että TKTL:n palvelin on huonosti konfiguroitu: Last-Modified -otsake, joka kertoo milloin resurssia on muokattu, määrittelee tulevaisuudessa olevan päivämäärän. Otsake Date taas kertoo hetken, jolloin pyyntö on tehty. Otsakkeissa on myös muuta hyödyllistä tietoa. Esimerkiksi otsake Cache-Control sisältää välimuistitoiminnallisuuteen liittyviä ohjeita; arvo no-cache määrittelee että sivun ajankohtaisuus tulee aina varmistaa palvelimelta. Huomaamme myös mielenkiintoisen arvon store, jota -- sen yleisessä käytössä olemisesta huolimatta -- ei määritellä HTTP/1.1 -otsakkeeseen Cache-Control liittyvässä osiossa (arvo store on määrittelemätön laajennus). Käytännössä TKTL:n verkkosivu pyrkii siihen, että selain ei tallenna sitä välimuistiin.

Nykyaikaisempi tapa on HEAD-pyynnön sijaan resurssin version tarkastamiseen on ETag-otsakkeen käyttö osana GET-pyyntöä. GET-pyyntöä suoritettaessa pyynnön mukana lähetetään otsakkeena resurssin version yksilöivä tunnus. Jos palvelimella oleva versio on sama kuin selaimen tiedossa oleva yksilöivä tunnus, palvelin voi palauttaa yksinkertaisesti vastauksen HTTP 304 Not Modified, eli resurssi ei ole muuttunut. Kuten HEAD-pyynnössä, myös ETag-otsaketta käyttävässä GET-pyynnössä resurssi tulee olla jo kerran ladattu.

$ curl -i hs.fi
HTTP/1.1 301 Object Moved
Location: http://www.hs.fi/
Content-Length: 0

HTTP on tilaton protokolla

HTTP on tilaton protokolla, eli se ei tarvitse jatkuvasti avoinna olevaa yhteyttä toimiakseen. Tämä tarkoittaa sitä, että HTTP ei osaa yhdistä samalta käyttäjältä tulevia pyyntöjä toisiinsa, jolloin jokainen tehty pyyntö käsitellään omana erillisenä pyyntönään. Käytännössä yhden web-sivustonkin hakeminen saattaa sisältää kymmeniä pyyntöjä, sillä jokaiseen sivuun liittyy joukko kuvia ja skriptitiedostoja, joista kukin on oma erillinen resurssinsa.

Vaikka HTTP on tilaton protokolla, on asiakkaan tunnistamiseen käytetty pitkään erilaisia kiertotapoja. Klassinen tapa kiertää HTTP:n tilattomuus on ollut säilyttää GET-muotoisessa osoitteessa parametreja, joiden perusteella asiakas voidaan identifioida palvelinsovelluksessa. Parametrien käyttö osoitteissa ei ole kuitenkaan ongelmatonta: osoitteessa olevia parametreja voi helposti muokata käsin, jolloin palvelinsovelluksesta saattaa löytyä tietoturva-aukkoja tai ei-toivottua käyttäytymistä.

HTTP-protokollan tilattomuus ei pakota palvelinohjelmistoja tilattomuuteen. Palvelimella tilaa pidetään yllä jollain tietyllä tekniikalla, joka taas ei näy HTTP-protokollaan asti. Nykyään yleisin tekniikka tilattomuuden kiertämiseen on evästeiden käyttö.

HTTP-protokollan tilattomuuden kiertäminen: evästeet

HTTP on tilaton protokolla, eli käyttäjän toimintaa ja tilaa ei pysty pitämään yllä puhtaasti HTTP-yhteyden avulla. Käytännössä suurin osa verkkosovelluksista kuitenkin sisältää käyttäjäkohtaista toiminnallisuutta, jonka toteuttamiseen sovelluksella täytyy olla jonkinlainen tieto käyttäjästä ja käyttäjän tilasta. HTTP/1.1 tarjoaa mahdollisuuden tilallisten verkkosovellusten toteuttamiseen evästeiden (cookies) avulla.

Asettamalla käyttäjän tekemän pyynnön vastaukseen eväste, tulee käyttäjän jatkossa pyyntöä tehdessä aina palauttaa kyseinen eväste pyynnön otsaketietoina. Tämä tapahtuu automaattisesti selaimen toimesta. Evästeitä käytetään istuntojen (session) ylläpitämiseen: istuntojen avulla pidetään kirjaa käyttäjästä useampien pyyntöjen yli.

Evästeet toteutetaan otsakkeiden avulla. Kun käyttäjä tekee pyynnön palvelimelle, ja palvelimella halutaan asettaa käyttäjälle eväste, palauttaa palvelun vastauksen mukana otsakkeen Set-Cookie, jossa määritellään käyttäjäkohtainen evästetunnus. Set-Cookie voi olla esimerkiksi seuraavan näköinen:

Set-Cookie: SESS57a5819a77579dfb1a1466ccceee22a0=0hr0aa2ogdfgkelogg; Max-Age=3600; Domain=".helsinki.fi"

Ylläoleva palvelimelta lähetetty vastaus ilmoittaa pyytää selainta tallettamaan evästeen. Selaimen tulee jatkossa lisätä eväste SESS57a5819a77579dfb1a1466ccceee22a0=0hr0aa2ogdfgkelogg jokaiseen helsinki.fi-osoitteeseen. Eväste on voimassa tunnin, eli tunnin kuluttua se voi poistaa. Tarkempi syntaksi evästeen asettamiselle on seuraava:

Set-Cookie: nimi=arvo [; Comment=kommentti] [; Max-Age=elinaika sekunteina] 
                      [; Expires=parasta ennen paiva] [; Path=polku tai polunosa jossa eväste voimassa]
                      [; Domain=palvelimen osoite (URL) tai osoitteen osa jossa eväste voimassa]
                      [; Secure (jos määritelty, eväste lähetetään vain salatun yhteyden kanssa)]
                      [; Version=evästeen versio]

Evästeet tallennetaan selaimen sisäiseen evästerekisteriin, josta niitä haetaan aina kun käyttäjä tekee kyselyn johonkin osoitteeseen. Evästeet lähetetään palvelimelle jokaisen viestin yhteydessä Cookie-otsakkeessa.

Cookie: SESS57a5819a77579dfb1a1466ccceee22a0=0hr0aa2ogdfgkelogg

Evästeiden nimet ja arvot ovat yleensä monimutkaisia ja satunnaisesti luotuja niiden yksilöllisyyden takaamiseksi. Samaan osoitteeseen voi liittyä myös useampia evästeitä. Yleisesti ottaen evästeet ovat sekä hyödyllisiä että haitallisia: niiden avulla voidaan luoda yksiöityjä käyttökokemuksia tarjoavia sovelluksia, mutta niitä voidaan käyttää myös käyttäjien seurantaan ympäri verkkoa.

HTML

"In '93 to '94, every browser had its own flavor of HTML. So it was very difficult to know what you could put in a Web page and reliably have most of your readership see it." -- Tim Berners-Lee

HTML on rakenteellinen kuvauskieli, jolla voidaan esittää linkkejä sisältävää tekstiä sekä tekstin rakennetta. HTML koostuu elementeistä, jotka voivat olla sisäkkäin ja peräkkäin. Elementtejä käytetään ohjeina dokumentin jäsentämiseen ja käyttäjälle näyttämiseen. HTML-dokumenteissa elementit avataan elementin nimen sisältävällä pienempi kuin -merkillä (<) alkavalla ja suurempi kuin -merkkiin (>) loppuvalla merkkijonolla (<elementin_nimi>), ja suljetaan merkkijonolla jossa elementin pienempi kuin -merkin jälkeen on vinoviiva (</elementin_nimi>).

HTML:ää voi ajatella myös puumaisena kielenä. Juurisolmuna on elementti <html>, jonka lapsina ovat elementit <head> ja <body>.

Jos elementin sisällä ei ole muita elementtejä tai tekstisolmuja (tekstiä), voi elementin avata ja sulkea samalla merkkijonolla: (<elementin_nimi />).

HTML:stä on useita erilaisia standardeja, joista viimeisin on HTML5, a.k.a. HTML

Elementtien tunnistaminen

HTML-elementit muodostavat niinkutsutun DOM-puun, joka sisältää kaikki HTML-sivun elementit ja niiden ominaisuudet. Tämän kurssin puitteissa DOM-puu jää hyvin pieneen sivurooliin, ja tärkeintä omalta kannaltamme on seuraavat asiat:

Lomakekentillä olevat nimi-attribuutit (name) ja niihin liittyvät arvot lähetetään lomakkeen attribuutin action määrittelemään osoitteeseen. GET-tyyppiset pyynnön lisäävät attribuutit osaksi osoitetta, POST-tyyppisissä pyynnöissä attribuutit kulkevat osana pyyntöä.

Tutkitaan alla olevaa lomaketta:

<form method="GET" action="http://t-avihavai.users.cs.helsinki.fi/lets/See">
  <label>Viesti <input type="text" name="viesti" /></label>
  <input type="submit" />
</form>

Kun lomakkeessa painetaan submit-nappia, lomake lähetetään GET-tyyppisenä pyyntönä osoitteeseen http://t-avihavai.users.cs.helsinki.fi/lets/See. Lomakkeesta lähtevät tiedot liittyvät lomakkeen kenttiin. Yllä olevassa lomakkeessa on tasan yksi lomakekenttä: viesti. Kentät tunnistetaan lomaketta lähetettäessä niiden name-attribuutin mukaan. Koska lomakkeen lähetystyyppi on GET (method="GET"), liitetään lomakkeen kentät osaksi osoitetta.

Esimerkiksi, jos lomakkeen viesti-kenttään kirjoitetaan teksti Hei, ja lomake lähetetään, kysely tehdään osoitteeseen http://t-avihavai.users.cs.helsinki.fi/lets/See?viesti=Hei. Huomaa että lomakkeen sisältämät tiedot on jo osana osoitetta.

HTML-dokumentin muodostamaa puuta läpikäydessä elementit voidaan tunnistaa sekä niiden nimen, että niiden tunnuksen perusteella. Tunnus, eli id, on erillinen elementit yksilöivä attribuutti. Esimerkiksi ylläolevassa lomakkeessa olevaan viestikenttään voi liittää tunnuksen seuraavasti:

<form method="GET" action="http://t-avihavai.users.cs.helsinki.fi/lets/See">
  <label>Viesti <input type="text" name="viesti" id="viesti" /></label>
  <input type="submit" />
</form>

Nyt lomakkeessa oleva viestikenttä voidaan tunnistaa myös sen tunnuksen perusteella. Tunnusten käyttämisen tarve selkenee kurssilla Web-selainohjelmointi, nyt vain todetaan että niitä tarvitaan. Jos haluat lisää tietoa aiheeseen liittyen, W3Schools tarjoaa hyvän pohjustuksen DOM-puiden läpikäyntiin ja muokkaamiseen.

Hello Web!

Tutustutaan tässä osiossa web-sovellusten rakenteeseen, sekä yksinkertaisten web-sovellusten toteuttamiseen servleteillä. Osa kappaleessa olevista esimerkeistä on tarkoitettu sillaksi HTTPn ja palvelimilla toimivien ohjelmistojen välillä. Sovellukset, joita tässä kappaleessa tehdään ovat osittain kivikautisia ja edustavat vahvasti myös huonoa ohjelmointityyliä. Haukumme itseämme jo nyt.

Servletit

Servletit ovat Javan teknologia dynaamisen palvelinpuolen web-toiminnallisuuden toteuttamiseen. Nimi Servlet tulee siitä, että servletit palvelevat (serve) käyttäjän tekemiä pyyntöjä: ne vastaanottavat pyyntöjä sekä myös vastaavat niihin.

Käytännössä Servlettejä toteutettaessa ohjelmoija perii javan valmiin HttpServlet-luokan, ja korvaavat yhden tai useamman sen tarjoamista metodeista. Yläluokka HttpServlet tarjoaa metodeja yleisimpien HTTP-protokollan pyyntöjen käsittelyyn. Esimerkiksi metodilla doGet käsitellään GET-tyyppinen pyyntö, kun taas metodilla doPost käsitellään POST-tyyppinen pyyntö.

Jokaisella pyyntöä käsittelevällä metodilla on parametrina kaksi rajapintaluokkaa: HttpServletRequest sisältää käyttäjän palvelimelle tekemän pyynnön tiedot ja HttpServletResponse sisältää käyttäjälle palvelimelta lähetettävän vastauksen. Rajapintaluokkien konkreettinen toteutus on käytettävän palvelimen toteuttajien vastuulla, Java tarjoaa vain rajapintamäärittelyt. Palvelinohjelmiston toteuttaja, me, taas käyttävät rajapintoja esimerkiksi pyynnön tietojen tarkasteluun ja vastauksen määrittelyyn.

Palvelimella toimiva web-sovellus voi koostua yhdestä tai useammasta Servletistä. Muutamissa esimerkeissä esiintyvä lets-sovellus sijaitsee osoitteessa http://t-avihavai.users.cs.helsinki.fi/lets/. Sovellukseen liittyy useampia Servlettejä, joista jokainen kuuntelee yhtä tai useampaa osoitetta. Esimerkiksi osoitteeseen http://t-avihavai.users.cs.helsinki.fi/lets/See on konfiguroitu Servlet, jonka tehtävänä on pyyntöön liittyvien otsakkeiden ja parametrien tulostaminen.

Servlettien kuuntelemat polut konfiguroidaan Javan web-sovelluksiin liittyvässä web.xml-tiedostossa.

Uudempi Servlet 3.0-spesifikaatio on osittain poistanut web.xml-tiedoston käytön servlettien konfiguroinnista: osa xml-tiedostoissa tapahtuvasta konfiguraatiosta on siirtynyt annotaatioden avulla tapahtuvaksi. Käytämme tällä kurssilla kuitenkin vielä hieman vanhempaa Servlet 2.5-spesifikaatiota: tausta-ajatuksena versiosta riippumatta on se, että servletit tulee kytkeä kuuntelemaan jotain osoitetta.

Erota käyttöliittymä ja sovelluslogiikka!

Yksi klassisimmista neuvoista ohjelmia rakentaessa on "erota sovelluslogiikka ja käyttöliittymä". Aiemmassa Hello World!- esimerkissämme näin ei ole tehty, vaan käyttöliittymä on osa sovelluslogiikkaa. Ei näin!

Sovelluslogiikan ja käyttöliittymän erottaminen on hyvin tärkeää ohjelmistotuotannon kannalta: isompia sovelluksia rakennettaessa useamman ihmisen tulee pystyä muokkaamaan sen eri osia samanaikaisesti. Jos kaikki on samassa tiedostossa, tiedoston luettavuus kärsii huomattavasti ja muokkaukset aiheuttavat lähes taatusti versionhallintakonflikteja. Sovelluksen eri osien testaaminen vaikeutuu myös huomattavasti, jos sovelluksen eri osia ei ole erotettu.

Paljon käytetty tapa käyttöliittymäkoodin ja sovelluskoodin erottamiseksi on luoda jokaiselle näkymälle oma sivu, johon Servlet-luokka pyynnön lopulta ohjaa. JSP-sivut luodaan WEB-INF-kansion sisälle omaan kansioon, jotta sivuihin ei pääse käsiksi suoraan selaimella. Tällä kurssilla jsp-sivut sisältävän kansion nimi on jsp.

Nyt Servletin kuuntelemaan osoitteeseen tuleva pyyntö ohjautuu lopulta kansiossa /WEB-INF/jsp/ olevaan tiedostoon hello.jsp.

Käytännössä siis pyyntö tapahtuu seuraavasti:

1. Käyttäjä tekee palvelimelle pyynnön

  käyttäjän selaimella tekemä pyyntö
     ----------------------->            palvelin


2. Palvelin päättelee pyynnön perusteella oikean servletin
   
  palvelin: pyynnön polku?
     ----------------->                   servlet

3. Servletin koodi suoritetaan

4. Vaihtoehtoinen tilanne: 

4a) Jos requestdispatcher-olion avulla ei määritellä seuraavaa 
    kohdetta, vastaus palautetaan käyttäjälle

4b) Muuten, pyyntö ohjataan määritellyyn osoitteeseen, esimerkiksi
    toiselle servletille. Servletin tai JSPn sisältämät komennot prosessoidaan
     palvelimella. Lopulta vastaus lähetetään takaisin käyttäjälle

Sovelluksen sijainti

Sovelluksemme sijainti palvelimella riippuu palvelimesta ja sovellukselle määritellystä konfiguraatiosta. Sovellukset ovat harvemmin palvelimen juuriosoitteessa, esim. http://palvelin.net/. Yleensä niille on oma aliosoite, esimerkiksi http://palvelin.net/sovellus. Tämä johtaa tilanteeseen, jossa sivulla käytettävien linkkien tulee olla dynaamisia. Esimerkiksi lomakkeiden lähettämisen tulee tapahtua sovellukselle.

Jos HTML-lomakkeen action-kenttä sisältää osoitteen /process, lomake lähetetään käytettävän palvelimen juuriosoitteeseen. Esimerkiksi jos lomake on palvelimella http://palvelin.net/, lähetettäisiin /process-osoitteeseen ohjautuva lomake käytännössä osoitteeseen http://palvelin.net/process -- riippumatta siitä, missä sovellus oikeasti on.

Tämän takia EL-kielessä pääsee käsiksi myös pyynnön tietoihin. Käyttämällä komentoa ${pageContext.request.contextPath} jsp-sivulla, sovelluksen osoitteen saa käyttöön. Käytännössä jos lomakkeen action-kentälle antaa arvon ${pageContext.request.contextPath}/process, lomake lähetetään sovelluksen sisältämään process-osoitteeseen, riippumatta siitä missä osoitteessa lomake oikeasti on.

Erillistä sovelluslogiikkaa

Jos sovelluksemme olisi hieman isompi ja jos koodi olisi Servlet-luokassa, tulisi Servlet-luokasta helposti hyvin raskas. Toteutetaan erillinen viestejä tuottava viestipalvelu. Viestipalvelun rajapinta on seuraavanlainen:

Juuri toteutettu poliittisia letkautuksia heittelevä Hei Maailma-sovellus on ylläpidettävyydeltään jo siedettävää luokkaa. Periaatteessa sovelluslogiikan vaihtaminen sellaiseksi, joka hakee viimeisimmän uutisen Helsingin sanomien etusivulta vaatisi vain uuden MessageService-rajapinnan toteuttavan luokan tekemistä ja sen vaihtamista HelloServlettiin.

Pyynnössä olevien parametrien käyttäminen

Pyynnön mukana voi lähettää parametreja palvelimelle. GET-tyyppisissä pyynnöissä parametrit ovat osana osoitetta. Esimerkiksi pyyntö osoitteeseen http://palvelin.net/sovellus?parametri1=arvo1&parametri2=arvo2 tekee käytännössä kyselyn osoitteessa http://palvelin.net/sovellus olevaan sovellukseen, ja antaa sovellukselle kaksi parametria. Parametrin parametri1 arvo on arvo1 ja parametri2-parametrin arvo on arvo2.

Jos ylläolevan Servlet-luokan kuuntelemaan osoitteeseen tehtäisiin pyyntö, jossa parametrin name arvona on Mikke, olisi processRequest-metodin suorituksen jälkeen attribuutin message arvo Hello Mikke.

Dynaamiset JSP-sivut: JSTL ja EL

JSP-sivut ovat dynaamista tietoa sisältäviä HTML-sivuja, jotka prosessoidaan palvelimella käyttäjälle näyttämistä. Palvelimella tapahtuvan prosessoinnin yhteydessä JSP-sivu muunnetaan servletiksi, servletti käännetään, ja lopulta servletin tuottama tulostus näytetään käyttäjälle. Tämä mahdollistaa asiakkaan pyyntöön liittyvien tietojen käsittelyn JSP-sivuilla: JSP-sivut ovat servlettejä ja pääsevät täsmälleen samoihin tietoihin käsiksi kuin servletit. JSP-sivuille on myös mahdollista tuottaa sisältöä suoraan Javalla:

That being said, don't do it.: Java-koodin käyttäminen JSP-sivuilla on indikaattori erittäin huonosta suunnittelusta ja johtaa hyvin vaikeasti ylläpidettäviin näkymiin. Erityisesti JSP-sivulla olevassa koodissa sijaitsevan virheen etsiminen on yhtä tuskaa: virheiden stack tracet liittyvät luonnollisesti JSP-sivusta käännetyn servletin koodiin.

On oleellista kuitenkin ymmärtää, että kaikki sivuilla näytettävä tieto luodaan palvelimella.

Java-koodin käyttäminen JSP-sivuilla on kielletty. Tarvitsemme dynaamisuutta sivuillemme: esimerkiksi listojen tulostaminen ei onnistu ilman ohjelmakoodia. Näimme aiemmin esimerkin EL-kielestä, jonka avulla sivulla voi käyttää ja näyttää pyynnössä olevia attribuutteja. EL-kieli oli alunperin osa JSTL-kieltä, joka on kokoelma tägikirjastoja JSP-sivuilla näytettävän datan prosessointiin.

EL

EL eli Expression Language on kieli, jolla pääsee käsiksi mm. pyynnössä oleviin attribuutteihin. EL-kielen lauseet ilmaistaan ${ }-merkinnällä, jonka sisällä on lauseke. Näimme aiemmin yksinkertaisen EL:n käyttöesimerkin jossa pyyntöön lisätään servletissä attribuutti, esim. request.setAttribute("viesti", "attribuutin arvo");, joka näytetään JSP-sivulla, esim. <p>${viesti}</p>.

Olioiden käsittely

EL-kielen piste-operaattorin . avulla pääsee käsiksi attribuutteina olevien olioiden get-metodeihin. Esimerkiksi lause ${auto.hinta} tekee auto-nimellä lisättyyn attribuuttiin metodikutsun getHinta(). Tutkitaan tätä hieman tarkemmin. Oletetaan että käytössämme on seuraava luokka Item.

Katso lisätietoa erilaisista EL-kielen mahdollisuuksista sivuilta oraclen sivuilta.

Todellisuudessa, kukaan ei toivottavasti ohjelmoi kauppalistaa siten, että jokainen tuote lisätään erillisenä attribuuttina. Tutustutaan seuraavaksi JSTL-kieleen, jonka avulla sivuille saadaan toiminnallisuutta mm. listojen läpikäyntiin.

JSTL

JSTL eli JSP Standard Tag Library on kokoelma XML-tägikirjastoja, joiden avulla JSP-sivuille voidaan lisätä dynaamista toiminnallisuutta. Ensimmäinen JSTL-spesifikaatio (vuodelta 2002) määrittelee JSTL:n tavoitteeksi JSP-sivuja toteuttavien ihmisten elämän helpottamisen: osalla käyttöliittymäsuunnittelijoista ei ole ohjelmointitaustaa. Koska JSTL-tägit ovat XML:ää, ei niiden käyttö haittaa käyttöliittymäsuunnittelussa. JSTL:ää ja HTML:ää sisältäviä JSP-sivuja voi tarkastella myös suoraan selaimella.

Web-sovellukset, hyvät ohjelmointikäytänteet ja peruskäsitteistöä

Tutustutaan seuraavaksi web-sovellusten ohjelmoinnissa käytettäviin perusohjelmointikäytänteisiin. Pohjustamme myös siirtymistä Spring-sovelluskehyksen käyttöön.

POST-pyyntötyypin käyttäminen

Erilaisiin pyyntötyyppeihin tulee reagoida eri tavalla. GET-pyynnöt ovat suoria pyyntöjä, joilla käyttäjät pyytävät palvelimella olevia resursseja. POST-pyynnöt taas ovat pyyntöjä datan muokkaamiseen. Esimerkiksi lomakkeet, joilla muokataan palvelimella olevaa dataa, tulee lähettää POST-tyyppisenä pyyntönä.

Ehkäpä tärkein syy tämän säännön noudattamiselle liittyy webissä oleviin hakukoneisiin. Hakukoneet käyvät verkon sivustoja jatkuvasti läpi uuden tiedon hakemiseen. Ne seuraavat sivuilla olevia linkkejä, mutta rajoittavat yleensä pyyntönsä GET-tyyppisiin pyyntöihin. Jos sivuilla olevat normaalit linkit mahdollistavat tiedon poistamisen, sivujen läpikäynti hakukoneiden toimesta voi poistaa sivulla olevan datan.

Jos käyttäjän tekemällä POST-tyyppisellä pyynnöllä muokataan sivulla olevaa dataa (esim. datan lisääminen lomakkeen avulla), tulee käyttäjä ohjata tekemään uusi GET-tyyppinen pyyntö pyynnön prosessoinnin jälkeen. Tällä pyritään poistamaan mahdollisuus POST-tyyppisten pyyntöjen uudelleentekemiseen esimerkiksi F5-näppäintä painettaessa, ja se helpottaa huomattavasti sovelluksen sisäisen rakenteen suunnittelua. Jokaisella servletillä on täsmälleen yksi vastuu: yksi on tiedon lisäämiseen, toinen listaamiseen jne..

Käytännössä käyttäjän ohjaaminen uuden pyynnön tekemiseen tapahtuu palauttamalla POST-pyyntöön HTTP-statuskoodi 303 (tai 302) ja osoite uuteen sijaintiin. Kun selain saa "sivu muuttanut" -viestin, hakee se automaattisesti uudessa osoitteessa olevan sivun.

SOLID

Termi SOLID lanseerattiin Robert "Uncle Bob" Martinin toimesta 2000 luvun alussa. Termi sisältää hyviä olio-ohjelmoinnissa käytettäviä käytänteitä. SOLID on akronyymi seuraaville käsitteille: Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, ja Dependency inversion principle.

• Single responsibility principle: Oliolla tulee olla vain yksi selkeä vastuu.


• Open/closed principle: Komponenttien tulee olla avoimia laajennukselle, mutta suljettuja muokkaukselle. Käytännössä komponentille tehtävien muutosten ei tule aiheuttaa muutoksia komponenttia jo laajentaville ja käyttäville komponenteille.


• Liskov substitution principle: Jos komponentti vaihdetaan sitä laajentavaan komponenttiin, komponenttia käyttävien sovellusten ohjelmien toiminnallisuuden ei tule muuttua.


• Interface segregation principle: Erottele rajapinnat toiminnallisuuksien perusteella. Monta asiakas/tapauskohtaista rajapintaa on parempi kuin yksi yleinen rajapinta.


• Dependency inversion principle: Käytä abstraktioita, älä ole riippuvainen konkreettisista toteutuksista.

Käytännössä SOLID on lista oliosuunnittelun periaatteita, joita seuratessa järjestelmän ylläpidettävyys ja kehitettävyys on huomattavasti helpompaa. Haluamme että omat web-sovelluksemme seuraavat yllälistattuja periaatteita.

Front Controller pattern

Front Controller on suunnittelumalli, jossa kaikille pyynnöille tarjotaan keskitetty käsittelypaikka. Käytännössä kaikki web-sovellukseen liittyvät pyynnöt ohjataan aluksi yhdelle kontrollipalvelulle, esimerkiksi servletille, joka ohjaa ne eteenpäin riippuen pyynnöstä ja pyynnössä haluttavasta resurssista.

Tyypillinen esimerkki Front Controllerin käytöstä on käyttäjän oikeuksien varmistaminen. Koska kaikki pyynnöt ohjataan ensin tietylle servletille, voidaan servletissä tarkistaa mm. käyttöoikeuksien olemassaolo, sekä mahdollisesti hakea käyttäjäkohtaisia tietoja. Toinen esimerkki on Wizard-tyyppiset sovellukset, joissa sivujen näyttöjärjestys on erittäin tärkeä. Tässä Front Controller voi helposti kontrolloida sivujen näyttöjärjestystä.

Front Controller-suunnittelumallia käytetään web-sovellusten toteuttamiseen liittyvän "bulk"-koodin piilottamiseen. Pyyntöjen prosessoinnit, ohjaukset, ym. tulee ohjelmointikielestä riippumatta aina toteuttaa. Sovelluskehykset tarjoavat valmiit rungot, joita käyttämällä ohjelmoija voi keskittyä web-sovelluksen oleellisempiin asioihin. Huomattava osa aktiivisessa käytössä olevista sovelluskehyksistä käyttää Front Controller-suunnittelumallia, mm. Zend, Symfony, Ruby on Rails, ASP .NET MVC ja Spring.

+ADw-marquee+AD4-web-palvelinohjelmointi+ADw-/marquee+AD4-

Dependency Injection

Dependency injection (riippuvuuksien injektointi) on suunnittelumalli, jonka avulla ohjelmiston käyttämät luokat voidaan päättää ajonaikaisesti. Oletetaan, että käytössämme on luokka HelloWorld, jonka ainut metodi on merkkijonon palauttava getMessage.

public class HelloWorld {
    public String getMessage() {
        return "Hello World!";
    }
}

Perinteisesti käytetyt oliot luodaan aina ohjelmoijan toimesta new-komennolla:

        // ...
        HelloWorld helloWorld = new HelloWorld();
        System.out.println(helloWorld.getMessage());
        // ...

Toinen lähestymistapa on määritellä käytössä olevat luokat erillisessä konfiguraatiotiedostossa. Sovellusta käynnistettäessä konfiguraatiotiedosto luetaan, ja sen perusteella luodaan oliot varastoon, eli oliokontekstiin, josta niitä voi tarvittaessa hakea. Esimerkiksi luokan HelloWorld voisi määritellä erilliseen konfiguraatiotiedostoon siten, että sille määritellään oma tunnus, jonka kautta siihen pääsee käsiksi:

    // ...
    <bean id="helloWorld" class="werkko.HelloWorld" />
    // ...

Sovellusta käynnistettäessä konfiguraatiotiedoston lataaja luo oliot oliokontekstiin, josta niihin pääsee käsiksi.

        // ...
        // luodaan context-olio, joka luo konfiguraatiotiedostossa (beans.xml)
        // määritellyt oliot oliokontekstiin
        ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
        
        // nyt oliota ei luoda itse, vaan sitä käytetään oliokontekstin kautta
        HelloWorld helloWorld = (HelloWorld) context.getBean("helloWorld");
        System.out.println(helloWorld.getMessage());
        // ...

Ok, mutta eikö tämä tee vaan kaikesta paljon vaikeampaa?

Ensisilmäyksellä koodi vaikuttaa hyvin paljon monimutkaisemmalta. Pohditaan kuitenkin tämän lähestymistavan hyötyjä.

1. Rajapintojen käyttäminen ja toteutusten vaihtaminen. Jos sovellus käyttää rajapintoja, voidaan todellinen toteutus piilottaa konfiguraation taakse. Tällöin komponentin toteuttajan ei tarvitse millään tavalla tietää rajapinnan toteuttavan luokan todellisesta toteutuksesta.
2. Sovellusten testaaminen. Sovelluksia testatessa halutaan usein käyttää ns. mock-olioita, joiden avulla voidaan tarkistaa että metodit ja luokat toimivat oikein. Käytettävien olioiden vaihtaminen onnistuu konfiguraatiotiedostoa vaihtamalla.
3. Olioiden parametrien injektointi. Koska olioiden luominen onnistuu konfiguraatiotiedoston avulla, voidaan olioiden parametrit myös määritellä konfiguraatiotiedostossa. Esimerkiksi tietokantaa käyttävien sovellusten testaamisessa kantana ei kannata käyttää tuotantokantaa. Tietokannan vaihtaminen onnistuu konfiguraatiotiedoston tai -parametrin vaihdolla.

Inversion of Control ja automaattinen riippuvuuksien haku

Käytännössä riippuvuuksien injektoinnissa on kyse kontrollin antamisesta sovelluskehykselle (Inversion of Control). Sen sijaan, että käyttäjä loisi itse ohjelman tarvitsemat oliot, olioiden luominen ja parametrien asettaminen tapahtuu sovelluskehyksen toimesta (käyttäjän määrittelemän konfiguraation pohjalta). Inversion of Controlin ja Dependency Injectionin hyödyt ovat mm.:

1. Ohjelman komponentteja voi testata helposti yksitellen: testatessa käytettäviä ominaisuuksia voi injektoida tarvittaessa.
2. Ohjelman kompleksisuus vähenee: eri komponentit voivat tuntea toiset komponentit vain rajapintojen kautta. Konkreettisia toteutuksia ei tarvitse nähdä, ja new-kutsuja ei juurikaan tarvitse tehdä.
3. Ohjelman käyttämien komponenttien vaihtaminen on helppoa.

Joissain sovelluskehyksissä riippuvuuksia ei tarvitse juurikaan konfiguroida, vaan sovelluskehys osaa päätellä ne ajonaikaisesti esimerkiksi annotaatioiden tai luokkahierarkian perusteella.

Case: Spring

Spring tarjoaa toiminnallisuuden beanien automaattiseen lataamiseen ja konfigurointiin. Käyttämällä automaattista komponenttien hakua (component-scan), sovellus osaa etsiä käytössä olevat komponentit, ja injektoida niitä tarvittaessa.

Jotta Spring ymmärtää, että luokka tulee ladata kontekstiin, tulee luokalle lisätä @Component-annotaatio. Esimerkiksi luokan HelloWorld saa ladattua automaattisesti oliokontekstiin, jos sillä on annotaatio @Component.

Spring ja Web

Spring on sovelluskehys, joka tarjoaa hyödyllisiä apuvälineitä Java (ja .NET)-sovellusten toteuttamisen ja testaamisen helpottamiseksi. Se perustuu Dependency Injection -suunnittelumalliin, joka mahdollistaa sovelluksen komponenttien toisistaan riippumattoman suunnittelun ja toteutuksen. Spring on komponenttipohjainen ja tarjoaa tukea mm. tietokanta-, web-, ja mobiilisovellusten toteuttamiseen.

Tutustutaan seuraavaksi yksinkertaisen web-sovelluksen toteuttamiseen Springin avulla: käytämme materiaalissa Springin versiota 3.1.2.RELEASE.

Hello Spring Web

Springin web-toiminnallisuuden peruskivi on Front Controller-suunnittelumalli sekä Dependency Injection. Spring-sovelluskehyksen web-toiminnallisuuden saa käyttöön lisäämällä projektin pom-tiedostoon seuraavan riippuvuuden.

Näkymän lisääminen

Puhuimme jo aiemmin siitä, että näkymän pitäisi olla JSP-sivuilla. Yllä olevaa sovellusta voi muokata siten, että se ohjaa pyynnön JSP-sivulle RequestDispatcher-oliota käyttäen. Esimerkiksi, jos käytössämme on kansiossa /WEB-INF/jsp/ oleva hello.jsp-tiedosto, voi pyynnön ohjata sivulle kuten aiemminkin:

Pyyntöjä käsittelevät metodit

Kontrolleriluokissamme on käytetty metodia processRequest(HttpServletRequest request, HttpServletResponse response) pyyntöjen käsittelyyn. Nimi processRequest on tuttu jo tehtävistä ennen Springiä. Mutta. Pyyntöä käsittelevän metodin nimen ei ole pakko olla processRequest, eikä sen tarvitse saada parametreinaan HttpServletRequest ja HttpServletResponse-olioita.

Spring päättelee annotaation @RequestMapping perusteella metodin, johon pyyntö ohjataan. Metodille määriteltävät parametrit ovat oikeastaan melko vapaat: parametriksi voi määritellä esimerkiksi Writer-olion, johon kirjoitettu teksti palautetaan käyttäjälle. HttpServletRequest- tai HttpServletRequest-olioita käytetään hyvin harvoin parametreina -- pyyntöä käsittelevä metodi voi myös olla parametriton. Seuraava metodi tuottaa käytännössä saman lopputuloksen kuin aiemmin näkemämme pyynnön JSP-sivulla ohjaava processRequest-metodi.

Parametri Model

Ehkäpä oleellisin ja eniten käytetty parametri on Model, jota käytetään pyynnön attribuuttien tallentamiseen. Model on rajapinta, johon Spring asettaa sopivan toteutuksen. Attribuutin lisääminen Model-oliolle sen metodin addAttribute avulla tarkoittaa käytännössä samaa kuin attribuutin lisääminen HttpServletRequest-oliolle metodilla setAttribute.

Spring syöttää @RequestMapping-annotaation omaavalle metodille parametrit sitä kutsuttaessa. Esimerkiksi edellisessä tehtävässä toteutettiin kontrolleriluokan metodi, joka näytti seuraavalta:

Sovelluslogiikan erottaminen kontrollereista: palvelut

Aiemmissa esimerkeissä ohjelmiin liittyvää sovelluslogiikkaa on laitettu milloin minnekin. Esimerkiksi salasanageneraattori-tehtävässä sovelluslogiikka, joskin vähäinen sellainen, oli osana Controller-luokkaa, metodissa generatePassword. Tämä ei ole hyvän ohjelmointityylin mukaista, sillä tarkoituksena on pitää Controller-luokkien koodimäärä mahdollisimman vähäisenä. Tavoitteena on erottaa sovelluslogiikka, eli ohjelman varsinainen "pihvi", omiin luokkiinsa, joita kutsutaan palveluiksi (Service). Jokainen palveluluokka tarvitsee oman rajapintansa, jotta luokkien väliset riippuvuudet eivät kohdistuisi toteutuksiin, vaan rajapintoihin. Tällöin palvelujen toteutuksia voidaan vaihtaa esimerkiksi testattaessa sovellusta.

Spring tarjoaa toiminnallisuuden palveluiden automaattiseen lisäämiseen @Autowired-annotaation avulla. Palvelut tunnistetaan @Service-annotaation avulla. Muokataan kappalessa 4.7 nähtyä Timo Soinin viestipalvelua siten, että se on oliokontekstiin ladattava palvelu.

Merkistöongelmat

Selainten ja palvelinten välisessä matalan tason kommunikoinnissa kaikki viestit siirretään binäärimuodossa joukkona nollia ja ykkösiä. Binäärimuotoinen data käännetään tekstiksi sovitun merkistökoodauksen avulla. Merkistökoodauksia on useita erilaisia, joista perinteisin lienee ASCII (American Standard Code for Information Interchange). ASCII-merkistössä jokainen merkki kuvataan 8 bitin avulla, josta 7 bittiä on merkeille (viimeinen on esim. pariteettibitti, jota voidaan käyttää merkin oikeellisuuden tarkistamiseen).

ASCII-merkistö ei juurikaan tue erikoismerkkejä. Esimerkiksi suomessa käytetyille ääkkösille ei ole kuvausta ASCII-merkistössä. Erikoismerkkien tarpeen vuoksi on kehitetty lukuisia standardeja, mm. ISO-8859-versio. Merkistö ISO-8859-1 sisältää tuen mm. lähes kaikille suomen kielessä käytettäville merkeille, ja sitä käytetään paljon selainten ja palvelinten välisessä kommunikoinnissa.

Nykyisin web-sivuilla eniten käytetty merkistö on UTF-8, joka kuvaa merkit 8-32 bitin avulla.

Koska erilaisia merkistöjä on satoja ja käyttöjärjestelmävalmistajilla on usein hieman standardeista poikkeava oma merkistö, tulee palvelimella ja selaimella olla yhteisymmärrys käytettävästä merkistöstä. Yhteisymmärrys luodaan sisällyttämällä pyynnön ja vastauksen otsakkeisiin tieto käytetystä merkistöstä.

Esimerkiksi pyyntöön voi lisätä otsakkeen Accept-Charset, jolla kerrotaan toivottu merkistö.

Accept-Charset: utf-8

Vastauksessa käytetään otsaketta Content-Type vastauksen sisällön tyypin ja käytetyn merkistön ilmaisemiseen.

Content-Type: text/html; charset=utf-8

HTML-sivuilla usein käytetään vielä lisäksi erillistä otsakekenttää, jolla pyritään valmistamaan käytetyn merkistön oikeellisuus. Esimerkiksi alla olevalla otsakkeella kuvataan sivun sisällöksi text/html ja merkistöksi utf-8.

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Merkistön sopiminen tapahtuu usein automaattisesti, mutta käytännössä ohjelmoijien tulee varautua merkistöongelmiin. Esimerkiksi servlettejä tehdessämme laitoimme servlet-koodin alkuun aina komennon response.setContentType("text/html;charset=UTF-8"), joka lisää Content-Type-otsakkeen vastaukseen.

        response.setContentType("text/html;charset=UTF-8");

Mielenkiintoisia ongelmia tarjoavat tilanteet, joissa otsaketiedoissa kerrotaan sisällön olevan tiettyä tyyppiä, mutta sisältö onkin erilaista. Jos merkistö on asetettu ASCII-muotoiseksi, mutta sisältö sisältää ASCII-aakkostossa määrittelemättömiä merkkejä, on sisällön tulkinta sovelluksen vastuulla. Merkistöongelmat voivat johtua myös palvelimen käyttämistä kolmannen osapuolen komponenteista. Esimerkiksi tietokannat tallentavat dataa yleensä tietyllä merkistöllä: jos ISO-8859-1 -merkistöä käyttävään tietokantaan tallennetaan UTF-8-muotoista dataa, tulee ainakin osa tallennetusta datasta olemaan korruptoitunutta.

Checklist

Jos sovelluksessasi on merkistöongelma, aloita seuraavista tarkistuksista:

1. Varmista että pyynnöt ja vastaukset sisältävät otsakkeen merkistön asettamiseen.
2. Varmista että JSP-sivujen alussa on alla oleva komento, jolla varmistetaan merkistön asetus.
   

   <%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"%>
   

3. Varmista että HTML-sivuilla on pyynnöt ja vastaukset sisältävät otsakkeen merkistön asettamiseen.
   

   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   

4. Varmista että tietokanta on konfiguroitu käyttämään haluttua merkistöä.
5. Varmista että palvelin on konfiguroitu käyttämään haluttua merkistöä.

Filtterit

Javan Servlet API sisältää servlettien lisäksi myös filttereitä. Filtterit ovat pyynnön ja vastauksen prosessoijia, joilla voidaan käsitellä pyyntöä ja vastausta ennen niiden servletille saapumista, sekä sen jälkeen kun servlet-koodi on suoritettu. Hyvin yleinen käyttötapa filtterille on merkistön asetus: yksittäistä filtteriä voidaan käyttää otsakkeiden asettamiseen pyyntöön ja vastaukseen.

Omia filttereitä toteutettaessa ohjelmoijan tulee periä rajapinta javax.servlet.Filter, sekä toteuttaa sen vaatimat metodit. Esimerkiksi alla on filtteri, joka tulostaa viestin ennen ja jälkeen seuraavan kohteen käsittelyä. Metodissa doFilter tehtävä komento chain.doFilter ohjaa pyynnön seuraavalle kohteelle, esimerkiksi servletille.

Filtterit konfiguroidaan web.xml-tiedostoon lähes samoin kuin servletit. Poikkeuksena on se, että servlet-nimen sijaan käytetään elementtiä nimeltä filter. Alla on konfiguroitu yllä luotu SimpleFilter kuuntelemaan kaikkia web-sovellukseen tulevia pyyntöjä.

    <filter>
        <filter-name>CharSetFilter</filter-name>
        <filter-class>wad.filter.SimpleFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>CharSetFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Spring-sovelluskehyksellä on valmis filtteri, joka muuttaa kaikki pyynnöt ja vastaukset (esimerkiksi) UTF-8 merkistöä käyttäväksi: CharacterEncodingFilter. Filtterin saa käyttöön lisäämälle sen web.xml-tiedostoon.

    <!-- Filtteri: Kaikki pyynnöt utf-8:ksi -->
    <filter>
        <filter-name>encoding-filter</filter-name>
        <filter-class>
            org.springframework.web.filter.CharacterEncodingFilter
        </filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
        </init-param>
        <init-param>
            <param-name>forceEncoding</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>encoding-filter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Jatkossa käytämme ylläolevaa filtteriä osana Spring-sovelluksiamme.

Tietokannat

Tietokanta on tietotekniikassa käytetty termi tietovarastolle. Se on kokoelma tietoja, joilla on yhteys toisiinsa. ... Tietokanta saattaa edustaa jotain selvästi rajattua kohdetta reaalimaailmasta. Tällainen kohde voi olla esimerkiksi yrityksen keräämät tiedot asiakkaistaan. - Wikipedia

Tietokanta on lähes aina webisoftan oleellisin osa, ilman sitä ei ole mitään näytettävää. - Mikael

Tähänastiset sovelluksemme ovat hukanneet käyttämänsä tiedot sovelluksen sammuessa. Tämä johtuu siitä että tietoa ei ole varastoitu mihinkään, vaan se on ollut vain sovelluksen muistissa. Tiedon säilymisen varmistamiseksi tieto tulee tallentaa pysyväismuistiin. Tietoa kuvataan usein taulumuotoisena, esimerkkinä seuraava taulu Henkilo:

Tietokantoja käytetään tiedon pysyväismuistiin (esim kovalevylle) tallentamiseen. Termiä tietokanta käytetään puhekielessä usein termin tietokannanhallintajärjestelmä korvaajana. Tietokannanhallintajärjestelmät (DBMS, Database Management System) ovat sovelluksia, jotka tarjoavat tukitoiminnallisuuksia tietokannan sydämen, eli tietokantamoottorin päälle. Tietokantamoottori tarjoaa toiminnallisuuden tiedon luomiseen, lukemiseen, päivittämiseen ja poistamiseen. Tätä toiminnallisuutta kutsutaan usein termillä CRUD (create, read, update and delete).

Esimerkiksi MySQL-tietokannanhallintajärjestelmää käytettäessä käyttäjä voi valita useamman tietokantamoottorin välillä, nykyään yleisin (ja oletus-) vaihtoehto on InnoDB-moottori.

Huomattava osa tietokannanhallintajärjestelmistä toteuttaa ACID-ominaisuudet (Atomicity, Concistency, Isolation, Durability), joilla pyritään turvaamaan järjestelmän luotettavuutta. Käytännössä ACID-ehtoja seuraamalla tallennettavat tiedot ovat eheitä myös virhetilanteissa. ACID koostuu seuraavista osista:

• Atomisuus (Atomicity): tietokantaan tehtävä kyselysarja suoritetaan kokonaan, tai sitä ei suoriteta lainkaan. Tähän liittyy käsite transaktio. Tietokantatransaktioiden avulla voidaan suorittaa joukko tietokantakyselyitä siten, että jos yksikin kysely epäonnistuu, yhtäkään ei suoriteta (palataan aiempaan tilaan). Esimerkiksi tilisiirtoja suorittaessa tehdään useampia käskyjä: "Ota rahaa tililtä 1, laita rahaa tilille 2" -- jos vain toinen onnistuu, rahat katoavat.
  
  
• Johdonmukaisuus (Consistency): tietokannan tulee olla jokaisen transaktion jälkeen eheässä ja johdonmukaisessa tilassa. Esim. tietokantaan tehtävien muutosten tulee näkyä muille tietokantaa käyttäville ohjelmille aina samalla tavalla, johdonmukaisesti.
  
  
• Eristyneisyys (Isolation): Tietokantaan tehtävät transaktiot eivät saa vaikuttaa toisiinsa, ja kesken oleva transaktio ei saa näkyä muille transaktioille.
  
  
• Pysyvyys (Durability): Kun transaktio on suoritettu loppuun, tehdyt muutokset eivät saa kadota järjestelmästä.

Tietokannanhallintajärjestelmät ovat erillisiä järjestelmiä, joihin tulee ottaa yhteys tietokantakyselyjä tehdessä. Käytännössä tietokannanhallintajärjestelmä kuuntelee jotain tiettyä porttia, johon yhteys otetaan. Useampi web-sovellus voi käyttää samaa tietokantapalvelinta. Tämä tuo haasteita skaalautuvuuden kanssa: jos tietokanta noudattaa ACID-periaatteita, ja tietokantaan tehtävien kyselyiden määrä on huomattava, voi tietokannan tehokkuus rajoittaa järjestelmän tehokkuutta. Eräs ratkaisu on tietokantapalvelimien monistaminen, mutta siinäkin on haasteena päivitysten synkronisointi palvelinten kesken.

Käsittelemme tässä kappaleessa relaatiotietokantojen käyttöä osana Javapohjaisia web-palvelinohjelmistoja. Esimerkeissä (ja tehtävissä) on käytössä Javalla kirjoitettu H2-tietokanta (v. 1.3.168), jonka saa käyttöön lisäämällä seuraavan riippuvuuden pom.xml-tiedostoon.

JDBC...

JDBC (Java Database Connectivity) on Javalle on määritelty standarditapa tietokantayhteyden luomiseen sekä tietoa muokkaavien ja hakevien kyselyjen suorittamiseen. Tausta-ajatuksena JDBCn kehitykselle on ollut yhteisen rajapinnan määrittely tietokannoille -- käytettävään tietokantaan täytyy voida ottaa yhteys, ja jokaiseen tietokantaan tulee pystyä tekemään kyselyitä. Kehitykseen on vaikuttanut ODBC, joka on vastaava projekti C-kielelle. JDBC tarjoaa suoran kytköksen valmiisiin ODBC-toteutuksiin.

Jotta JDBCn avulla voidaan ottaa yhteys tietokantaan, tulee käytössä olla tietokantakohtainen JDBC-ajuri. Käytännössä jokainen tietokannanhallintajärjestelmä tarjoaa JDBC-ajurin. JDBC-ajurin vastuulla on tietokantayhteyden luomiseen liittyvät yksityiskohdat sekä kyselytulosten muuntaminen JDBC-standardin mukaiseen muotoon.

// ...
String nimi = "nimi";
String salasana = "salasana";

String kysely = "SELECT * FROM user WHERE username = '"
                           + nimi + "' AND password = '" + salasana + "'";
// ...

Prepared Statement

Prepared Statement-kyselyt ovat valmiiksi määriteltyjä kyselyitä, joissa kyselyissä käytettävät arvot annetaan parametreina. Valmiita kyselyitä käyttämällä pystytään estämään ainakin osa SQL-injektioista, sillä parametreja käytettäessä varmistetaan että parametrien arvot liittyvät aina vain tiettyyn kenttään -- kyselyparametrit eivät "vuoda yli". Prepared Statement-kyselyt mahdollistavat myös kyselyiden optimoinnin, sillä kysely on aina samanmuotoinen.

Valmiit kyselyt määritellään Connection-olion prepareStatement-metodin avulla. Metodi palauttaa PreparedStatement-olion, johon kyselyn käyttämät arvot määritellään parametreina. Esimerkiksi SQL-injektioesimerkissä oleva kysely luodaan valmiiden kyselyiden avulla seuraavasti:

DataSource

DriverManager-luokkaa käytettäessä yhteys tietokantaan luodaan yleensä alusta asti. Yhteyden luominen voi kestää jopa sekunteja riippuen ajurin lataamisesta, palvelimen sijainnista ja käytössä olevasta infrastruktuurista. DriverManager-olion käyttöä suositellumpi tapa JDBC-yhteyksien luomiseen on DataSource-rajapinnan toteuttavan palvelun käyttö.

Eräs toteutus DataSource-rajapinnalle on Apache Commons-projektin DBCP-projekti. Commons DBCP-projektin saa käyttöön lisäämällä siihen liittyvän riippuvuuden pom.xml-tiedostoon.

RowMapper

Springin JDBC-komponentti tarjoaa myös tuen tulosten kytkemiseen olioihin. Oletetaan että käytössämme on seuraava luokka User:

"Olioita tietokannassa, häh?"

Huomaamme, että tietokantataulujen kuvaaminen luokkien avulla on oikeastaan aika loogista. Tietokantataulun nimi vastaa luokan nimeä ja taulun attribuutit (eli sarakkeiden nimet) ovat luokan attribuutteja. Jokainen luokasta luotava olio vastaa yhtä tietokantataulun riviä. Viitteet eri taulujen välillä voidaan taas kuvata viitteinä olioiden välillä.

Sovelluksia suunniteltaessa yksi lähestymistapa ongelma-alueeseen on tallennettavaa tietoa kuvaavien olioiden luonti. Tämä tapahtuu luonnollisesti yhteistyössä asiakkaan kanssa, jolloin voidaan varmistaa että puhutaan asiakkaan ja ongelma-alueen käyttämällä kielellä. Tutkitaan seuraavaa lentokentän hallintajärjestelmän kuvausta:

Case: Lentokenttä

He told us: "...Basically what we need is a system for monitoring aircrafts and airports. Each aircraft has a unique identifier, e.g. LOL-52, and a numeric capacity. Airports on the other hand reside in a location, have a unique identifier and a name, e.g. e.g. LOL for Derby Field United States and FUN for International Tuvalu. Each airport can host one or more aircrafts..."

Ongelma-alueen purkaminen lähtee perinteisesti liikkeelle substantiivien etsimisellä.

He told us: "...Basically what we need is a system for monitoring aircrafts and airports. Each aircraft has a unique identifier, e.g. LOL-52, and a numeric capacity. Airports on the other hand reside in a location, have a unique identifier and a name, e.g. LOL for Derby Field United States and FUN for International Tuvalu. Each airport can host one or more aircrafts..."

Tämän jälkeen substantiiveista erotetaan pääkäsitteet, pääkäsitteiden attribuutit, ja ei-oleelliset käsitteet. Pääkäsitteitä ovat aircraft ja airport, ja system on ei-oleellinen käsite. Loput ovat pääkäsitteiden attribuutteja.

Pääkäsitteiden attribuutit löytyy etsimällä lisätietoa antavia lauseita (esim. has a, in a, ...). Yllä olevasta esimerkistä löytyy seuraavat käsitteet attribuutteineen.

DAO-pattern

DAO-pattern (Data Access Object) on suunnittelumalli, jossa tiedon tallennusmekanismi kapseloidaan sovelluslogiikalle näkymättömäksi. DAO-rajapinnan ideana on mahdollistaa tallennusmekanismin helppo vaihtaminen: sovellus voi aluksi säilyttää olioita esimerkiksi muistissa -- rajapinnan käyttäjän ei tarvitse välittää toteutuksesta. Toteutetaan aiemmin esitellyille olioille DAO-oliot ja niihin liittyvät toteutukset.

Käytetään perinteistä CRUD-tyyliä rajapintojen metodien nimeämiseen.

Object Relational Mapping ja JPA

ORM-työkalut (Object Relational Mapping) tarjoavat mm. toiminnallisuuden tietokantataulujen luomiseen määritellyistä luokista. Työkalut hallinnoivat luokkien välisiä viittauksia ja ylläpitävät mm. tietokannan eheyttä. Käyttäjän vastuulle jää yleensä sovellukselle tarpeellisten kyselyiden toteuttaminen niiltä osin kun niitä ei tarjota valmiiksi.

Relaatiotietokantojen käsittelyyn on kehitetty joukko ORM-sovelluksia joista nimekkäin lienee Hibernate. Oracle/Sun standardoi olioiden tallentamisen relaatiotietokantoihin JPA (Java Persistence API) -standardilla. JPA:n toteuttavat kirjastot (esim. Hibernate, EclipseLink) abstrahoivat relaatiotietokannan, ja mahdollistavat kyselyjen tekemisen suoraan ohjelmakoodista.

Käytämme tällä kurssilla EclipseLink-kirjaston versiota 2.4.0, jonka saa käyttöön lisäämällä projektiin seuraavat riippuvuudet. Alempi riippuvuus tuo käyttöön JPA2-APIn.

Persistence ja EntityManagerFactory

Luokkaa Persistence käytetään EntityManagerFactory-olion ohjelmalliseen luomiseen. Persistence-luokan luokkametodille createEntityManagerFactory annetaan parametrina käytettävän konfiguraation nimi, jonka perusteella tiedostosta persistence.xml etsitään oikea konfiguraatio. Luokkaa Persistence käytetään vain silloin, jos sovellusta halutaan käyttää erillisenä web-ympäristöstä (esim. yllä ollut demo) -- web-kontekstissa tarvittavat luokat injektoidaan automaattisesti.

Luokka EntityManagerFactory on tehdasluokka, josta saadaan entiteettien tallentamista hallinnoivia EntityManager-olioita.

EntityManager

EntityManager hallinnoi entiteettejä ja niiden tallennusta tietokantaan. Sovelluskehys -- tai sovelluskehittäjä -- luo EntityManager-olion tarpeen vaatiessa. EntityManager tarjoaa joukon palveluita, joista oleellisimmat ovat olion tietokantaan lisääminen (metodit persist ja merge), poistaminen (metodi remove) ja hakeminen (metodi find).

EntityManager tarjoaa toiminnallisuuden tietokantatransaktioiden hallintaan. Metodi getTransaction() palauttaa EntityTransaction-olion, jota käytetään transaktioden aloittamiseen (metodi begin) ja lopettamiseen (metodi commit).

JPA ja Web

Spring ja transaktiot

Spring tarjoaa apuvälineitä transaktioiden hallintaan. Luokka JpaTransactionManager delegoi transaktioiden käsittelyn EntityManager-olioille. Käytännössä transaktiot voidaan määritellä metodi- tai luokkatasolla annotaation @Transactional avulla. Tällöin annotaatiolla @Transactional merkittyä metodia suoritettaessa metodin alussa aloitetaan tietokantatransaktio, jossa tehdyt muutokset viedään tietokantaan metodin lopussa. Jos annotaatio @Transactional määritellään luokkatasolla, se koskee jokaista luokan metodia.

Merkkijonot entiteettien avaimina

Joissain tapauksissa entiteettien avainarvot halutaan saada tietoon jo ennen tietokantaan tallentamista. Tällöin avainarvoina käytetään sovelluksen itse luomaa mahdollisimman yksilöivää arvoa. Jos avainarvoja ei luoda tietokannan toimesta, on mahdollista että useammalla entiteetillä on sama avainarvo. Tällöin pyritään siihen, että saman avainarvon kahdesti luomisen todennäköisyys on mahdollisimman pieni.

Yleisin ratkaisu satunnaisen avaimen luomiseen on satunnaisen merkkijonon käyttäminen avaimena. Javalla hyvin satunnaisen merkkijonon saa luotua esimerkiksi UUID-luokan avulla. UUID-luokka arpoo merkkijonon joukosta, jossa on noin 2¹²⁸ vaihtoehtoa.

Esimerkiksi yllä luotua GroceryItem-entiteettiä tulee muuttaa seuraavasti, jotta sille voidaan asettaa merkkijonoavain. Avaimen generointi voi tapahtua esimerkiksi luokan parametrittomassa konstruktorissa tai osana luokkaa käyttävää palvelua.

Huomaamme tietokantalogiikassa vieläkin melko paljon toisteisuutta. Esimerkiksi CRUD-operaatiot ovat lähes aina samanlaiset. Tutustutaan seuraavaksi Spring Data JPA-projektiin, joka pyrkii vähentämään tietokantalogiikan toteutukseen tarvittavan koodin määrää.

Spring Data JPA

Olemme huomanneet että iso osa tietokantatoiminnoista on valmiiden operaatioiden toistamista. Käytännössä lähes jokainen JPA:n kanssa paininut paljon tietokantakyselyitä luova sovelluskehittäjä on jossain vaiheessa luonut itselleen hieman seuraavankaltaisen pohjan, jonka perimällä saa käyttöön oleellisimmat toiminnot.

Omien kyselyiden toteuttaminen

Spring Data JPA ei tarjoa kaikkia kyselyitä valmiiksi. Jos tarvitset tietynlaisen kyselyn, sinun tulee yleensäottaen myös määritellä se. Laajennetaan aiemmin määriteltyä rajapintaa AircraftRepository siten, että sillä on metodi List<Aircraft> findByCapacity(Integer capacity) -- eli hae koneet, joilla on tietty kapasiteetti.

Kerrosarkkitehtuuri

Kerrosarkkitehtuuri jakaa sovelluksen kerroksiin; tiedon tallentamiseen ja hakemiseen liittyvään logiikkaan, sovelluksen palveluihin liittyvään logiikkaan, käyttöliittymästä tehtyjä pyyntöjä ohjaavaan kerrokseen, ja käyttöliittymäkerrokseen.

N-tier -arkkitehtuurilla tarkoitetaan yleisesti sovelluksen jakamista itsenäisiin osiin, jotka toimivat vuorovaikutuksessa muiden osien kanssa. Client-Server -arkkitehtuuri on esimerkki 2-tier arkkitehtuurista, 3-tier -arkkitehtuuri taas esimerkiksi jakaa käyttöliittymän, sovelluslogiikan, ja tietokantalogiikan erillisiksi osioikseen. Tällä kurssilla kerrosarkkitehtuurista puhuessamme tarkoitamme yleisesti ottaen seuraavaa jakoa:

• Käyttöliittymälogiikka (JSP)
• Pyyntöjen ohjaus ja syötteiden tarkistus (Controller)
• Palvelulogiikka (Service)
• Tallennuslogiikka (Repository)

Tiedon hakemiseen ja tallentamiseen liittyvässä logiikassa käytetään lähes aina valmiita komponentteja, esim. JPA tai Spring Data JPA. Alimman kerroksen toiminnallisuus -- relaatiotietokannat, key/value -tietokannat, dokumenttitietokannat, jne.. -- ovat web-sovelluskehittäjän näkökulmasta "done", eli omaa ei kannata lähteä toteuttamaan.

Sovelluksen oleellisin osa on palveluissa, eli keskitasossa. Sovelluslogiikka sisältää toiminnallisuuden, joka tekee sovelluksestamme arvokkaan. Sovelluslogiikka käyttää alempana olevan tietokantakerroksen tarjoamia palveluita. Sovelluslogiikkakerros sisältää yleensä myös transaktioiden hallinnan.

Sovelluslogiikkakerroksen päällä on käyttöliittymäkutsuja ohjaava kerros, "kontrollikerros". Käyttöliittymäkutsuja ohjaavan kerroksen tehtävänä on toimia rajapintana sovelluskerroksen ja käyttöliittymän välillä. Se vastaanottaa käyttäjän tekemiä pyyntöjä ja ohjaa niitä eteenpäin tarpeellisille palveluille. Kontrollikerroksen tulee olla mahdollisimman ohut; siinä käytetään sovelluskerroksen tarjoamaa toiminnallisuutta. Kutsun suorittamisen jälkeen kontrollikerros palauttaa dataa jossain muodossa. Javascript-kutsulla voi pyytää XML- tai JSON-muodossa olevaa dataa, jonka näyttäminen tapahtuu selainpuolella. Toisaalta, palautettu data voidaan ohjata erilliselle käyttöliittymän renderöintipalvelulle, joka luo näytettävän HTML-sivun.

Kontrollikerroksen päällä on käyttöliittymä. Käyttöliittymiä voi olla useita erilaisia. Kaikille yhteistä on se, että ne tekevät pyyntöjä web-sovelluksen tarjoamiin osoitteisiin.

Sovelluslogiikkakerros

Sovelluslogiikka jaetaan oliosuunnittelun periaatteiden mukaisesti toiminnallisuutta tarjoaviin palveluihin, joita kontrollikerros käyttää. Spring tarjoaa hyvät välineet sovelluslogiikan ja kontrollikerroksen erottamiseen. Tutustumme seuraavaksi kontrolliluokan ja sovelluslogiikan yhteistoimintaan. Pieni kertaus ennen sitä.

Inversion of Control ja Dependency Injection

Jokaisella oliolla on oma selkeä vastuualueensa, ja niiden sekoittamista tulee välttää. Inversion of Control ja Dependency Injection ovat suunnitelumalleja, joilla pyritään vähentämään olioiden turhia riippuvuuksia.

Inversion of Control

Perinteisissä ohjelmistoissa luokkien ilmentymien luominen on ohjelmoijan vastuulla. Huomasimme jo aiemmin että Spring luo käyttöömme luokkia joita tarvitsemme: Kontrollin käännöllä tarkoitetaan ohjelman toiminnan hallinnan vastuun siirtämistä sovelluskehykselle ja ohjelmaa suorittavalle palvelimelle.

Dependency Injection

Dependency Injectionin tehtävänä on syöttää riippuvuudet silloin kun niitä tarvitaan.

Käytännössä siis: palvelin ja sovelluskehys ottaa vastuuta luokkien hallinnoinnista. Sovelluskehys syöttää riippuvuudet niitä tarvittaessa. Molemmat toiminnallisuudet ovat oleellisia kerrosarkkitehtuurin kerrosten toisistaan erottamisessa.

Kontrolleritaso

Kontrolleritaso kuuntelee käyttöliittymältä tulevia pyyntöjä, ja vastaanottaa lähetettyä dataa. Käytännössä sovelluskehyksissä pyynnöt ohjataan kontrollereille erillisen front controllerin kautta. Front controller kuuntelee kaikkia sovellukselle ohjattuja pyyntöjä. Springiä käytettäessä käytämme Springin omaa DispatcherServlet-toteutusta, joka toimii front controllerina.

Kontrolleritason ensisijaisena vastuuna on pyyntöjen kuuntelu, pyyntöjen ohjaaminen oikealle palvelulle, sekä tuotetun tiedon ohjaaminen oikealle näkymälle. Jotta palveluille ei ohjata epäoleellista dataa, esimerkiksi huonoja arvoja sisältäviä parametreja, on kontrolleritason vastuulla myös pyyntöparametrien validointi. Parametrien validointi tapahtuu käytännössä käsin, joko siten, että ohjelmoija itse toteuttaa validoinnin, tai jotain olemassaolevaa validointimekanismia käyttämällä.

Pyyntöparametrien validointi

Ensimmäinen askel pyyntöparametrien validointiin on pyyntöparametrien asettaminen odotetun tyyppisiin muuttujiin. Esimerkiksi numeerisia arvoja saavan parametrin oikeellisuuden voi varmistaa asettamalla sen Integer-tyyppiseen muuttujaan. Poikkeustapauksessa tiedämme heti, että käyttäjä on yrittänyt syöttää sovellukselle virheellisiä arvoja.

Alkeellinen muuttujien arvojen validointi toteutetaan kontrolleriin tai erilliseen validointiluokkaan. Oletetaan että seuraava lomake sijaitsee tiedostossa grocery-item-form.jsp, lomakkeen lähetys ohjautuu luokassa GroceryItemController olevalle metodille addGroceryItem. Lisäksi käytössämme on erillinen rajapinta GroceryItemService, joka tarjoaa metodit tallentamiseen ja listaamiseen.

Lomakkeet ja oliot

Kun pohdimme lomakkeita hieman enemmän, huomaamme että ne sopivat melko hyvin olio-ohjelmointiajatteluun. Lomakkeissa syötetään usein tietoa johonkin käsitteeseen -- luokkaan liittyen -- ja yhden lomakkeen sisältämät tiedot kuvautuvat helposti oliona. Onkin itseasiassa suhteellisen helppoa rakentaa oma luokka, joka muuntaa pyynnössä olevat parametrit tietynlaiseksi olioksi.

Ajatustasolla olion luominen pyynnöstä tapahtuu luomalla ensin oliosta ilmentymä, ja sen jälkeen käymällä pyynnön parametreja läpi. Jos pyynnössä on parametri, joka on saman niminen kuin olion attribuutti, asetetaan parametrin arvo olion attribuutiksi. Huomattava osa yleisessä käytössä olevista sovelluskehyksistä tekee tämän jollain tavalla puolestamme. Spring-sovelluskehyksessä tämän toiminnallisuuden saa käyttöön lisäämällä Springin konfiguraatioon komennon <mvc:annotation-driven />. Myös mvc-nimiavaruus tulee lisätä Springin konfiguraatioon.

Olioiden validointi

Lomakkeiden ja lähetettävän datan validointi on web-sovelluksille hyvin oleellista. Emme halua että käyttäjä pääsee lähettämään sovelluksellemme toisten koneilla suoritettavaa koodia. Ensimmäinen askel -- jonka olemme jo ottaneet -- on tallennettavan datan järkevä esitys. Käytämme datan esittämiseen olioita, joihin on määritelty sopivat kenttien tyypit. Tämä helpottaa työtämme jo hieman: esimerkiksi numerokenttiin ei saa asetettua merkkijonoja.

Tämä ei kuitenkaan vielä riitä.

Javassa on oma API Bean-tyyppisten olioiden validoinnille: Bean Validation API (Javadoc). Bean validation API on, kuten muutkin JSRt (Java Specification Request, vain rajapinta, jolla voi olla useampi toteuttaja. Käytämme JSR-303 -apin, eli Bean Validation APIn, toteutuksena Hibernate Validator-projektia (dokumentaatio), jonka saamme käyttöömme lisäämällä pom.xml-tiedostoon seuraavan riippuvuuden.

Oliomuuttujien validointi

Muuttujien validointia varten tarkistettaville muuttujille määritellään annotaatiot. Muokataan aiemmin käytettyä luokkaa Person siten, että henkilöllä tulee olla henkilötunnus, nimi ja sähköpostiosoite.

Käytännössä siis validointi onnistuu Hibernate Validator-komponentin avulla annotaatioilla. Lisätään validointi seuraavaksi osaksi kontrolleriluokkaa.

Pyynnössä saatavan olion validointi kontrollerissa

Pyynnössä saatavan olion, joka on merkitty annotaatiolla @ModelAttribute validointi on helpohkoa. Kun olemme lisänneet Spring-konfiguraatioon komennon <mvc:annotation-driven/>, saamme käyttöön muitakin toiminnallisuuksia kuin olioiden generoinnin pyynnöstä. Yksi ominaisuus on olioiden validointi. Spring lataa automaattisesti käyttöönsä validointikehyksen, jos sellainen löytyy käytössä olevista kirjastoista. Jos olemme lisänneet Hibernate Validator-projektin osaksi pom.xml-tiedostoa, on se käytössämme automaattisesti.

Itse olion validointi tapahtuu lisäämällä kontrollerimetodissa olevalle @ModelAttribute-annotaatiolle merkatulle oliolle annotaatio @Valid (javax.validation.Valid;).

Springin lomakkeet ja BindingResult

Spring tarjoaa käyttöömme tägikirjaston lomakkeiden luomiseen JSP-sivulla. Lomakekirjaston saa JSP-sivulla käyttöön lisäämällä sivun alkuun seuraavan komennon.

Validointi ja entiteetit

Vaikka esimerkissämme käyttämäämme Person-luokkaa ei oltu merkitty @Entity-annotaatiolla -- eli se ei ollut tallennettavissa JPAn avulla tietokantaan -- mikään ei estä meitä lisäämästä sille @Entity-annotaatiota. Toisaalta, lomakkeet voivat usein sisältää tietoa, joka liittyy useaan eri talletettavaan olioon. Tällöin onkin fiksua luoda erillinen lomakkeen validointiin tarkoitettu lomakeolio, Form Object, jonka pohjalta luodaan tietokantaan tallennettavat oliot kunhan validointi onnistuu. Erilliseen lomakeobjektiin voi täyttää myös kannasta haettavia listoja ym. ennalta.

Model ja Redirect

Kun käyttäjä ohjataan tekemään uusi pyyntö redirect:-komennon avulla, selaimelle käytännössä palautetaan HTTP statuskoodi 303 (tai 302), sekä uusi osoite. Tällöin selain tekee pyynnön uuteen osoitteeseen. Koska HTTP on tilaton protokolla, ei sillä ole välineistöä käyttäjän pyyntöjen yhdistämiseen: aiemmassa pyynnössä käytössä oleva data ei ole käytössä seuraavassa pyynnössä.

Tämä on yleensä täysin hyväksyttävää, ja toivottavaakin, mutta joissain tapauksissa ohjelmoija haluaa aiemmasta pyynnöstä tietoja myös seuraavaan pyyntöön. Tyypillinen käyttötapaus on tietyn informaatioviestin lisääminen sivulle, johon käyttäjä ohjataan. HTTP-protokollan tarjoamat evästeet mahdollistavat tiedon katoamisen kiertämisen: jos kaivattu tieto tallennetaan sessioon, on se olemassa myös seuraavalla pyynnöllä. Vastaava toiminnallisuus on myös useassa sovelluskehyksessä valmiina.

Spring tarjoaa pyynnöissä käytettävän parametrin RedirectAttributes, johon voi tallentaa attribuutteja, jotka halutaan näkyville seuraavalla pyynnöllä. Käytännössä RedirectAttributes-olio tallentaa attribuutit sessioon, josta ne lisätään Model-olion attribuutteihin seuraavan pyynnön yhteydessä.

Jotta RedirectAttributes toimii, on Spring-konfiguraatiossa oltava merkkijono <mvc:annotation-driven />.

Pohditaan tilannetta, jossa luomme uutta Person-oliota. Kun henkilö on luotu, käyttäjä ohjataan sivulle, jossa on henkilön tiedot. Kun käyttäjä tulee sivulle ensimmäisen kerran, sivulla näytetään myös viesti "New person created!". Lisätään Person-luokalle attribuutti id, jota käytetään henkilön tunnistamiseen.

REST

REST (representational state transfer) on HTTP-protokollaan perustuva arkkitehtuurimalli erityisesti web-pohjaisten sovellusten toteuttamiseen. Taustaidea on periaatteessa yksinkertainen: osoitteilla määritellään haettavat ja muokattavat resurssit, pyyntömetodit kuvaavat resurssiin kohdistuvaa operaatiota, ja pyynnön rungossa on tarvittaessa resurssiin liittyvää dataa. HTTP:n GET- ja POST-komentojen lisäksi REST-sovellukset käyttävät ainakin PUT ja DELETE-pyyntöjä. Esimerkiksi yksinkertainen henkilöstörekisteri voitaisiin toteuttaa seuraavilla osoitteilla ja pyyntötavoilla.

• GET osoitteeseen /person palauttaa henkilöiden tiedot tai osajoukon henkilöiden tiedoista -- riippuen toteutuksesta.
• PUT osoitteeseen /person/{id} lisää tai muokkaa henkilön tietoja tietyllä tunnuksella. Henkilön tiedot lähetetään pyynnön rungossa.
• DELETE osoitteeseen /person/{id} poistaa henkilön tietyllä tunnuksella.
• POST osoitteeseen /person luo uuden henkilön pyynnössä lähetettävän datan pohjalta. Palvelun vastuulla on päättää henkilölle tunnus.

Oleellisia asioita RESTissä ovat resurssien nimentä web-osoitteita käyttäen sekä HTTP-protokollan tarjoamien pyyntötyyppien käyttö. Osoitteissa käytetään substantiivejä -- ei getPerson?id={tunnus} vaan /henkilo/{tunnus}, ja pyynnöt kategorisoidaan pyyntötyyppien mukaan. DELETE-tyyppisessä pyynnössä poistetaan, POST-tyyppisellä pyynnöllä lisätään, PUT-tyyppisellä pyynnöllä joko lisätään tai päivitetään, ja GET-tyyppisellä pyynnöllä haetaan. Kuten normaalissakin HTTP-kommunikaatiossa, GET-pyyntöjen ei tule muuttaa dataa.

REST on hyödyllinen arkkitehtuurimalli mm. olemassaolevien jo hieman ikääntyneiden palveluiden kapselointiin. Sovelluskehittäjä voi kehittää uuden käyttöliittymän, ja käyttää vanhaan sovellukseen liittyvää toiminnallisuutta REST-rajapinnan kautta. REST-arkkitehtuuriin perustuvat palvelut ovat nykyään hyvin yleisiä ja niiden luomiseen on tehty huomattava määrä apuohjelmia. Yksinkertaisen REST-palvelun voi luoda esimerkiksi suoraan olemassaolevasta NetBeansin Web Services -osiossa olevien toimintojen avulla.

Luodaan seuraavaksi oma REST-arkkitehtuuria seuraava kontrolleri aiemmin nähtyjen Person-olioiden luontiin ja muokkaamiseen.

REST-tyyppinen arkkitehtuuri Person-olioiden tallentamiseen ja muokkaamiseen

JSON-muotoista dataa käyttävä REST-sovellus

REST-tyyppisten palveluiden ei aina kannata palauttaa kokonaista HTML-sivua: REST-rajapintaa käytetäänkin usein ilman erillistä HTML-sivua. Tarvitsemme kuitenkin jonkun tavan tiedon esittämiseen ja siirtämiseen. Yleisimmät tiedonsiirtomuodot tällä hetkellä ovat JSON ja XML, joista ensimmäisen suosio kasvaa jatkuvasti. Olemme tällä kurssilla lähinnä kiinnostuneita JSON-muotoisesta datasta.

JSON

JSON (JavaScript Object Notation) on Javascriptin käyttämä tiedonsiirtoformaatti. JSON-formaatin yksi hienous on se, että JSON-objekteja voi lukea suoraan Javascript-olioiksi. Tämä tulee tutummaksi kurssilla Web-selainohjelmointi. JSON mahdollistaa avain-arvo -parien ja listojen esittämisen. Oletetaan, että käytössämme on seuraava olutta kuvaava luokka Beer.