Luento 3.6. Verkkopalvelun arkkitehtuuri ja keskeinen toiminnallisuus

Luentokerran tavoitteena on perehtyä verkkopalveluarkkitehtuurin yleisiin periaatteisiin ja kaikille verkkopalveluille yhteisiin toimintoihin ja ominaisuuksiin:

• Tietokantapohjainen Web-teknologialla toteutettu verkkopalvelu perustuu yleisesti kolmikerrosmalliin (three-tier model)
• Verkkopalveluiden kolme keskeistä toimintoa ovat pääsynhallinta (access), käyttäjän tunnistaminen (authentication) ja käyttöoikeuksien hallinta (authorization).
• Verkkopalvelun ohjelmallinen toteuttaminen edellyttää käytännössä aina istuntojen (session) soveltamista.
• Verkkopalvelun turvallisuuteen ja tietoturvaan liittyviä asioita ei voi korostaa koskaan liikaa.
• Verkkopalveluihin liittyy edellä mainittujen lisäksi lukuisia yleisiä ominaisuuksia, jotka on syytä ottaa huomioon verkkopalveluiden suunnittelu- ja toteutustyössä.

Luentokerran aikana käsiteltävien ominaisuuksien toteuttaminen yleiseen, uudelleenkäytettävään sovelluskehykseen on välttämätöntä kun pyritään sovellusten toteutustyön tehostamiseen.

Asiakas-palvelin –malli vs. kolmikerrosmalli

• Verkkopalvelun arkkitehtuuri perustuu yleisesti asiakas-palvelin -malliin
• Tietokantapohjaisessa (verkko)palvelussa asiakas-palvelin -malli toimii seuraavasti:
  1. Käyttäjä käyttää palvelua asiakassovelluksen (user agent) välityksellä.
  2. Asiakassovelluksen ja palvelimen välinen vuorovaikutus toteutetaan tarkoitukseen sopivalla protokollalla.
  3. Toimintaperiaate: asiakassovellus tekee kyselyitä tietokantaan käyttäjän ohjaamana ja näyttää kyselyn tulokset käyttäjälle käyttöliittymässään.

• Webissä asiakas-palvelin mallin toteuttaminen suoraan Web-selaimen ja tietokantapalvelimen yhdistelmänä on periaatteessa mahdollista (älykäs asiakasohjelma). Ratkaisu ei kuitenkaan sellaisenaan ole yleisesti käytössä huonon selainyhteensopivuuden takia
• Tietokantapohjaisen verkkopalvelun arkkitehtuuri noudattaa yleensä ns. kolmikerrosmallia (three-tier model).
• Kolmikerrosmallissa Web-selaimen ja tietokantapalvelimen väliin toteutetaan välikerros, joka toimii asiakkaana tietokantapalvelimelle ja palvelimena Web-selaimelle.

Kolmikerrosmalli ja PHP

Opintojaksolla käytössä olevilla teknologioilla kolmikerrosmallin välikerros toteutetaan Web-palvelimen ja PHP-ympäristön yhdistelmänä:

1. Välikerroksen toiminnallisuus ohjelmoidaan PHP-kielellä.
2. Selaimen ja WWW-palvelimen välinen vuorovaikutus hoidetaan tuttuun tapaan HTTP-protokollalla.
3. PHP-tulkki käyttää tietokantapalvelinta asiakasohjelman roolissa toimivan funktiokirjaston välityksellä.
4. Tietokantapalvelimen ja -asiakkaan välinen vuorovaikutus toteutetaan käytössä olevan tietokannan omalla protokollalla tai yleisellä Open Database Connectivity (ODBC) -protokollalla.

PHP tukee sekä ODBC-protokollaa että yleisimpien tietokantapalvelimien omia protokollia: MySQL, PostgreSQL, MS Access, IBM DB2, Oracle, ...

ODBC-protokollan käyttäminen parantaa (ainakin teoriassa) sovelluksen siirrettävyyttä eri palvelinympäristöjen välillä. Tietokanta voidaan abstrahoida myös sopivalla ohjelmistokirjastolla. PHP-kielen tapauksessa eräs vaihtoehto on ADOdb.

Verkkopalvelun keskeiset toiminnot

• Verkkopalveluiden kolme keskeistä toimintoa ovat:
  • Pääsynhallinta (access): verkkopalvelun mahdollisten käyttäjien rajaaminen.
  • Käyttäjän tunnistaminen (authentication): verkkopalvelun käyttäjien tunnistaminen.
  • Käyttöoikeuksien hallinta (authorization): verkkopalvelun toimintojen käyttöoikeuksien rajoittaminen.

Web-teknologialla toteutettujen palvelujen käyttöliittymät toteutetaan HTML-lomakkeisiin. Käy läpi Web-lomakkeita käsittevä luentomateriaali vuodelta 2012 ja varmista että hallitset lomakkeiden perusteet.

Pääsynhallinta

Yksinkertaisin keino pääsynhallinnan toteuttamiseen on HTTP-protokollan HTTP Basic Authentication -mekanismin käyttäminen:

• Web-resurssin noutamiseen oikeuttavat tiedot välitetään HTTP-pyynnön Authorization-nimisessä otsikossa.
• HTTP-perusautentikointia käyttävä verkkopalvelu on helppo tunnistaa tavasta, jolla selain kysyy käyttäjältä tunnuksen ja salasanan: tiedot syötetään erikseen aukeavaan (taustaväriltään usein harmaaseen) dialogiin, jonka sulkeminen Peruuta-painikkeella aiheuttaa HTTP-virhekoodin 401 Unauthorized.
• Pääsynhallinta voidaan toteuttaa myös esimerkiksi IP-osoitteiden avulla (ongelmia!).

• Käyttäjän tunnistaminen voidaan pääsynhallinnan tavoin periaatteessa toteuttaa HTTP-perusautentikoinnin avulla. Pääsynhallinnan ja käyttäjän tunnistamisen ero: ensimmäisessä tunnus voi olla yhteinen joukolle ihmisiä, jälkimmäisessä jokaisella käyttäjällä on oma henkilökohtainen tunnus.
• Yleensä käyttäjän tunnistamiseen toteutetaan räätälöity toiminnallisuus, jolloin tunnistamiseen liittyvät käyttöliittymät ja esimerkiksi virheilmoitukset voidaan toteuttaa halutulla tavalla => käyttöliittymien yhtenäisyys, käyttäjän toiminnan tukeminen.

Käyttöoikeuksien hallinta

Käyttöoikeuksien hallinta voidaan toteuttaa esimerkiksi seuraavilla tavoilla:

1. Erittäin yksinkertaisessa sovelluksessa käyttöoikeuksiin ei välttämättä tarvitse ottaa kantaa ollenkaan: kaikilla käyttäjillä on samat oikeudet.
2. Käyttöoikeudet määritellään jokaiselle käyttäjälle erikseen.
3. Käyttöoikeudet jaetaan käyttäjille roolien avulla: jokaisella käyttäjällä on (yksi) rooli.
4. Käyttöoikeudet jaetaan käyttäjille profiilien avulla: jokaisella käyttäjällä on yksi tai useampi profiili.

Käyttöoikeuksien jakaminen roolien avulla on toimiva ratkaisu silloin, kun palvelun käyttäjäryhmän jäsenet voidaan helposti ryhmitellä eri rooleihin. Profiilien käyttäminen mahdollistaa käyttöoikeuksien määrittelemisestä rooleja joustavammin.

Käyttäjän tunnistaminen: toteuta myös nämä

• Rekisteröityminen: käyttäjä syöttää haluamansa tunnistetiedot (yleensä tunnus ja salasana) ja mahdollisesti muita tietoja itsestään.
  • Tunnuksen ja salasanan pituutta ja muotoa halutaan mahdollisesti rajoittaa
  • Salasana on syytä tallentaa tietokantaan tiivisteenä ja soveltaa ns. suolaamista.

• Sisäänkirjautuminen rekisteröinnissä syötettyjen tietojen avulla (tunnus ja salasana)
• Käyttäjän on halutessaan voitava kirjautua ulos palvelusta.
• Palvelun toimintojen toteutuksessa on voitava (helposti) varmistaa, että käyttäjä on kirjautunut sisään. Käyttäjään liittyviin tietoihin on päästävä suoraviivaisesti käsiksi.
• Käyttäjän on pystyttävä halutessaan vaihtamaan salasanansa käytettävyys- ja tietoturvasyistä.
• Käyttäjät unohtavat salasanansa aina silloin tällöin. Käyttäjän on pystyttävä selviämään tilanteesta itsenäisesti. Esimerkkiratkaisu: käyttäjällä on mahdollisuus tilata rekisteröitymisen yhteydessä määriteltyyn sähköpostiosoitteeseen linkki, jonka valitsemalla hän voi määritellä itselleen uuden salasanan.

Verkkopalvelu ja toimintojen luonne

Nykyaikainen Web-arkkitehtuuri (http://www.w3.org/TR/webarch/) jakaa verkkopalveluiden toiminnot kahteen luokkaan, turvallisiin ja ei-turvallisiin:

• Turvallinen toiminto (safe intercation):
  • toiminto vastaa luonteeltaan kyselyä/hakua
  • toiminnon suorittaminen ei muuta sovelluksen tilaa
• Ei-turvallinen toiminto (unsafe interaction):
  • toiminto vastaa luonteeltaan tilausta
  • toiminnon suorittamisen seurauksena sovelluksen tila muuttuu: käyttäjän lisätään sähköpostilistalle tai rekisteröidään palveluun, toiminnon seurauksena syntyy maksutapahtuma ja niin edelleen.
  • Huom: ei-turvallinen tarkoittaa tässä eri asiaa kuin vaarallinen (dangerous).

Toiminnon luonne & välitystavan valinta

Selain välittää käyttäjän syötteen palvelimelle HTTP-pyyntönä. Lomakesoveltajan valittavana ovat seuraavat HTTP-metodit:

• get-metodi:
  • turvalliset toiminnot: haku/kysely, sovelluksen tila ei muutu
  • kaikki pyyntöön liittyvät tiedot koodataan mukaan URI-tunnisteeseen
• post-metodi:
  • ei-turvalliset toiminnot: tilaus, sovelluksen tila muuttuu
  • pyyntöön liittyvät tiedot koodataan HTTP-pyynnön otsikkotietoihin
  • käyttäminen perusteltua myös arkaluontoisia tietoja (esim. salasana, yhteystiedot tai luottokortin numero) välitettäessä

Myös Web-selaimessa näkyviä eroja! Mitä?

Pysyvät URI-tunnisteet

Huomioi myös URI-tunnisteiden pysyvyys (stability) ja ennustettavuus (predictability):

• Resurssia edustava representaatio URI-tunnisteen on tarjolla ajanhetkestä riippumatta
• Resurssin URI-tunnisteen tulee pysyä muuttumattomana
• URI-tunniste on sama jakelukontekstista (käyttäjä, käyttötilanne ja päätelaite) riippumatta: representaatio räätälöidään jakelukontekstiin sopivaksi
• HTTP-protokollan get-metodi mahdollistaa pysyvien URI-tunnusten toteuttamisen: kirjanmerkit, linkit ja välimuistin toiminta.
• Esimerkki: pysäkin numero 3525 aikataulu. Myös ongelmia! Mitä?

Muista myös nämä!

Verkkopalvelun käyttäjä on liian usein pulassa Web-lomakkeiden kanssa.

• Keinoja käyttäjän tukemiseen:
  • Ohjeet ja opasteet: Mitä kenttään on syötettävä? Syötteen pakollisuus? Oletusten ja rajoitusten esittäminen!
  • Virheilmoitukset ja korjausehdotukset: Selkeä ilmoitus virheellisestä syötteestä korjausehdotuksineen. Syötteen dynaaminen tarkastaminen (Ajax)?
  • Viestit onnistuneista toiminnoista: (”Levyn Nieminen & Litmanen tiedot lisätty”).
  • Syötteen kierrättäminen: Kerran syötetyn tiedon käyttäminen oletusarvona tulevissa lomakkeissa jne.
  • Vaiheittain täytettävä lomake: Suuremman lomakkeen jakaminen selkeisiin kokonaisuuksiin, joiden välillä käyttäjä voi navigoida lomaketta täyttäen.

Käyttäjän tukeminen on käytännössä otettava huomioon jo sovellusarkkitehtuurin suunnittelussa.

Istunnon hallinta

• HTTP-protokollan tilattomuus on jo tuttua, mutta kerrataanpa vielä: HTTP-protokollassa ei ole sisäänrakennettua keinoa sovelluksen tilan ylläpitämiseen.
• Sovelluksen tilan ylläpitäminen toteutetaan istuntojen (session) tuella:
  • Sisäänkirjautuminen
  • Sisällön/toimintojen näyttäminen käyttöoikeuksien perusteella
  • Sovelluksen mukauttaminen käyttäjän mieltymysten (preference) perusteella
  • Käyttäjän toiminnan seuraaminen, esimerkiksi lokitiedon kerääminen
  • Ostoskorin toteuttaminen

• Huomaa, että istuntoja voidaan hyödyntää myös ilman käyttäjän tunnistamista. Tällöin sovelluksen tilaa ei kuitenkaan voida säilyttää istuntojen välillä.
• Asiakas-palvelin -mallissa istunto toteutetaan siten, että asiakkaalle annetaan yksikäsitteinen istunnon tunniste, jonka asiakas toimittaa takaisin palvelimelle jokaisen pyynnön yhteydessä. Istunnon tiedot säilytetään palvelimella ja niihin päästään käsiksi istunnon tunnisteen perusteella.

Istunnot käytännössä

• Istunnon tunnisteen välittämiseen on useita tapoja:
  • Evästeet (Cookie): Eväste on (lyhyt) merkkijono, jonka verkkopalvelu välittää asiakkaalle HTTP-vastauksen mukana. Eväste tallennetaan käyttäjän koneelle joko istunnon ajaksi tai pysyvästi kovalevylle. Asiakas lähettää evästeen palvelulle jokaisen palvelupyynnön mukana. Evästeitä nimitetään usein kekseiksi, pipareiksi tai jopa taikapipareiksi
  • HTTP GET: Istunnon tunniste sijoitetaan muiden pyynnön parametrien tapaan osaksi URI-tunnistetta (example.php?sessionid=xyz123) => ongelmia!
  • HTTP POST: Istunnon tunniste sijoitetaan HTML-lomakkeen piilokenttään.

• Evästeen voimassaoloaika voidaan määritellä evästä asetettaessa. Eväste voidaan myös aktiivisesti poistaa siinä vaiheessa, kun istunto lopetetaan.
• Istunnot ovat erittäin keskeisessä roolissa verkkopalvelun toiminnallisuuden toteuttamisessa. Esimerkiksi yleiskäyttöinen ostoskorin toiminnallisuus toteutetaan istuntojen avulla.

Verkkopalvelun tietoturva

Verkkopalvelun tietoturvaan liittyviä riskitekijöitä (vrt. Welling ja Thompson 2004):

• Luottamuksellisen tiedon näkyvyys (exposure of confidential data).
• Tiedon häviäminen tai tuhoutuminen (loss or destruction of data).
• Tiedon muokkaaminen (modification of data)
• Palvelun käytön esto (denial of service)
• Virheet ohjelmistossa (errors in software)
• Kiistäminen (repudiation): toiminnossa osallisena ollut taho kiistää tekemisensä (tavaran tilaaminen, maksullisen palvelun käyttäminen).

Tietoturvan toteuttamisessa on tehtävä kompromissi verkkopalvelun käytettävyyden, suorituskyvyn, kustannustehokkuuden ja turvallisuuden välillä. Esimerkkejä:

• Salasanan säännöllinen kysyminen verkkopankissa heikentää käytettävyyttä.
• Kaiken palvelun välittämän tiedon salaaminen syö palvelimen ja verkon resursseja.

Paikkansa pitävä teesi: tietoturva on ennen kaikkea asennekysymys!

Verkkopalvelu: yleisiä ominaisuuksia

Verkkopalvelut sisältävät näennäisestä erilaisuudestaan huolimatta lukuisia yleisiä ominaisuuksia:

• Uutisten lisääminen, muokkaaminen ja julkaiseminen (esim. RSS-muoto)
• Verkkopalvelun kansainvälistäminen (i18n) ja kotoistaminen (l10n)
• Erilliset tai integroidut ylläpitäjän työvälineet (esim. käyttäjien hallinta)
• Tiedonhaun apuvälineet (esim. avainsanahaku, taggaaminen, hakemistot, tagipilvet, )
• Sovelluksen räätälöinti sivupohjien tuella
• Monikanavaisuus ja mukautuminen (laiteriippumattomuus & saavutettavuus)
• Käytön tilastointi ja analysointi
• Sisällön ylläpitämisen työvälineet
• Mielipidekyselyt, äänestäminen
• Keskustelualue, vieraskirja, kalenteri, ostoskori, ...

Verkkopalvelun toimintojen suunnittelumantra: Lisää/Poista/Muokkaa/Kopioi (CRUD)

Lisää yleisiä ominaisuuksia (vrt. Django)

Django listaa ansiokkaasti joukon laadukkaan Web-sovelluskehyksen ominaisuuksia:

• Pysyvän tietosisältökerroksen automatisointi ORM (object-relational mapping) –menetelmällä (Object-relational mapper)
• Automaattiset ylläpitokäyttöliittymät (Automatic admin interface)
• Tyylikkäät URI-tunnisteet (Elegant URL design)
• Sivupohjamekanismi (Template system)
• Välimuisti (Cache system)
• Kansainvälistäminen (Internationalisation)

Lisää kehysvaihtoehtoja

Djangon rinnalla on toki muitakin vaihtehtoja

• Ruby on Rails (”Web development that doesn’t hurt”)
• Codeigniter ("CodeIgniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications.")
• Kolmikon Django, Ruby on Rails ja CodeIgniter keskeinen tavoite on lisätä sovelluskehittäjän käytössä olevaa ilmaisuvoimaa ja siten mahdollista verkkopalveluiden ketterä ja kustannustehokas toteuttaminen.

Kohti AJAXia

Kolmikerrosmalli esittelee Web-hypermediajärjestelmän teknisen perustan.

AJAX (Asynchronous JavaScript And XML) mahdollistaa entistä vuorovaikutteisempien sovellusten kehittämisen ja esittelee lisää kerroksia arkkitehtuuriin.

Ks. havainnollinen [kaaviokuva AJAX-periaatteesta](http://www.webstepbook.com/supplements-2ed/slides/chapter12-ajax-xml-json.shtml#slide7).

Kohti RESTiä

Kolmikerrosmalli esittelee Web-hypermediajärjestelmän teknisen perustan.

REST (Representational State Transfer) -malli (Fielding 2000) laajentaa ja yleistää mallia kohti hajautettua Web-hypermediaa, vrt.

Kuva: (Fielding, 2000)

Lopuksi

• Sekä verkkopalvelun teknisestä arkkitehtuurista että toiminnallisuudesta löytyy verkkopalvelusta toiseen toistuvia tekijöitä
• Näiden toistuvien tekijöiden tunnistaminen on erittäin hyödyllistä monellakin tavalla:
  • Verkkopalvelun toiminnallisuuden suunnittelutyö voidaan ainakin osittain tehdä uusien toimintojen keksimisen sijaan olemassa olevista vaihtoehdoista valitsemalla ja/tai vaihtoehtoja räätälöimällä
  • Verkkopalvelujen toteuttamisen tueksi voidaan rakentaa yleinen kehysjärjestelmä, joka minimoi toteutustyöhön liittyvät rutiinit ja mahdollistaa aikaresurssien keskittämisen varsinaisen sovelluslogiikan toteuttamiseen

• PHP-kieli mahdollistaa tietokantojen helpon käyttämisen ja tukee esimerkiksi istuntojen hyödyntämistä ja muita yleisiä toimintoja
• PHP-sovellusten tekemisen tueksi löytyy myös erilaisia sovelluskehyksiä, joihin tutustuminen on erittäin suositeltavaa ennen laajempien järjestelmien toteuttamista
• Kehyksiä ei välttämättä tarvitse käyttää sellaisenaan; tärkeintä on ideoiden kartoittaminen ja soveltaminen. Eri käyttötarkoituksiin taipuvien sovelluskehysten käyttöä (CodeIgniter, Django, Ruby on Rails, ...) on kuitenkin syytä harkita vakavasti.