Toiminnallinen määrittely v. 1.0 Päivitetty 6.11.2000 klo 20:07
Janne Kankaanpää 2 (2) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0 6.11.2000 Janne Kankaanpää, Tomas Björnfot, Jussi Isotupa Sovelluskehikon toiminnallisen määrittelyn ensimmäinen versio TOIMINNALLINEN MÄÄRITTELY 2
Janne Kankaanpää 3 (3) Sisällys DOKUMENTIN VERSIOHISTORIA...2 SISÄLLYS...3 1 JOHDANTO...4 1.1 TARKOITUS JA KATTAVUUS...4 1.2 TUOTE...4 1.3 MÄÄRITELMÄT, TERMIT JA LYHENTEET...4 1.4 VIITTEET...5 1.5 YLEISKATSAUS DOKUMENTTIIN...5 2 YLEISKUVAUS...7 2.1 YMPÄRISTÖ...7 2.2 TOIMINTA...7 2.3 KÄYTTÄJÄT...7 2.4 YLEISET RAJOITTEET...7 3 SOVELLUSKEHIKON TIEDOT...8 3.1 SOVELLUSKEHIKON TIETOSISÄLTÖ JA KÄSITTEET...8 3.2 KÄYTTÖINTENSITEETTI...10 3.3 KAPASITEETTIVAATIMUKSET...11 4 TOIMINNOT...12 4.1 YLEISTÄ TOIMINNOISTA...12 4.2 JÄRJESTELMÄN TOIMINNOT...12 5 ULKOISET LIITTYMÄT...18 5.1 LAITTEISTOLIITTYMÄT...18 5.2 OHJELMISTOLIITTYMÄT...18 5.3 TIETOLIIKENNELIITTYMÄT...18 6 MUUT OMINAISUUDET...19 6.1 SUORITUSKYKY JA VASTEAJAT...19 6.2 TURVALLISUUS JA SUOJAUKSET...19 6.3 YLLÄPIDETTÄVYYS...19 6.4 SIIRRETTÄVYYS/KANNETTAVUUS, YHTEENSOPIVUUS...19 6.5 OPEROINTI...20 7 SUUNNITTELURAJOITTEET...20 7.1 STANDARDIT...20 7.2 LAITTEISTORAJOITTEET...20 8 JATKOKEHITYSAJATUKSIA...20 TOIMINNALLINEN MÄÄRITTELY 3
Janne Kankaanpää 4 (4) 1 JOHDANTO 1.1 Tarkoitus ja kattavuus Tämän dokumentin on tarkoitus määritellä projektissa tuotettavan sovelluskehikon toiminnallisuus. Projektissa toteutettavalle demosovellukselle tehdään erillinen, oma toiminnallinen määrittelynsä sekä tekninen määrittelynsä. Sen vuoksi tässä dokumentissa ei puututa millään tavoin demosovelluksen toimintoihin, vaan keskitytään pelkästään sovelluskehikkoon. Katso erikseen palautetteva demosovelluksen toiminnallinen määrittely [1]. Dokumentti on tarkoitettu kuvaamaan sovelluskehikon toiminnot projektiryhmälle ja mahdollisesti sovelluskehikon käyttäjille, jotka ovat projektin päätyttyä lopputuotteen käyttäjiä. Dokumentin on tarkoitus kattaa kaikki se toiminnallisuus, joka sovelluskehikolta vaaditaan sille laaditussa vaatimusmäärittelyssä [2]. Sovelluskehikolle ei tehdä erillistä käyttöohjetta muun dokumentaation lisäksi, joten tässä dokumentissa on tarkoitus kattaa sovelluskehikon koko toiminnallisuus mahdollisimman tarkasti. 1.2 Tuote Projektin tarkoituksena on tuottaa sovelluskehikko käyttäjien tunnistamiseen ja käyttöoikeuksien hallintaan hajautetussa. Tarkoitus on, että sovelluskehikkoa voidaan käyttää hyvin heterogeenisissa ympäristöissä, joissa käyttäjätietolähteet ja muut tietolähteet ja rajapinnat ovat vaihtelevan tyyppisiä. Tästä syystä sovelluskehikko pyritään rakentamaan mahdollisimman modulaariseksi, jotta käyttöoikeuksien hallinta ja käyttäjien tunnistaminen voisi tapahtua yhtenäisellä tavalla ympäristöstä riippumatta. 1.3 Määritelmät, termit ja lyhenteet Projektiryhmä Ryhmä, joka tekee sovelluskehikkoa kurssin Tik-76.115 puitteissa (katso projektisuunnitelma [3]) Asiakas A-Ware Oy, jolle projektiryhmä tekee projektia (katso projektisuunnitelma) Sovelluskehikko Projektissa toteutettava lopputuote Sovellus Asiakkaan toteuttama sovelluskehikkoa hyödyntävä ohjelma Sovelluskehikon käyttäjä Asiakkaan ohjelmoija, joka käyttää sovelluksen tekemiseen projektissa valmistunutta sovelluskehikkoa Sovelluksen käyttäjä Asiakkaan sovellusta käyttävä henkilö tai prosessi Komento Komento on esimerkiksi jokin operaatio tai toiminto, jonka sovelluksen käyttäjä voi suorittaa sovelluksessa. TOIMINNALLINEN MÄÄRITTELY 4
Janne Kankaanpää 5 (5) Oikeus Sovelluksen käyttäjä tarvitsee komennon suorittamiseen oikeuden, joka tarkastetaan ennen kuin komento suoritetaan. Oikeuteen voi sisältyä lipuke. Kredentiaalit Käyttäjätietojen osa, joka sisältää tarpeelliset tiedot käyttäjän oikeuksien tarkistamiseen sovelluksessa. Kredentiaalit koostuvat esimerkiksi käyttäjän yksilöivästä tunnisteesta ja joukosta oikeuksia. Lipuke Tapa, jolla pidetään yllä tietoa siitä, onko jokin asia voimassa. Lipuke kertoo voimassaolon esimerkiksi ajan tai suorituskertojen avulla. 1.4 Viitteet [1] Demosovelluksen toiminnallinen määrittely, 7.11.2000, versio 1.0 tai uudempi, Mickey Shroff & Timo Lämsä,, http://www.niksula.cs.hut.fi/~jjkankaa//demotoiminnallinenmaarittely. pdf [2] Vaatimusmäärittely, 16.10.2000, versio 1.0 tai uudempi, Tomas Björnfot,, http://www.niksula.cs.hut.fi/~jjkankaa//vaatimusmaarittely.pdf [3] Projektisuunnitelma, 16.10.2000, versio 1.0 tai uudempi, Jussi Isotupa ym.,, http://www.niksula.cs.hut.fi/~jjkankaa//projektisuunnitelma.pdf [4] Sun Microsystems Inc., Java 2 Platform, Enterprise Edition, 12.10.2000, http://www.javasoft.com/j2ee/ [5] Sun Microsystems, Code Conventions for the JavaTM Programming Language, 20.4.1999, http://java.sun.com/docs/codeconv/index.html 1.5 Yleiskatsaus dokumenttiin Dokumentin ensimmäinen luku on johdanto toiminnalliselle määrittelylle. Johdanto kertoo dokumentin tarkoituksen, esittelee sovelluskehikon lyhyesti sekä sisältää määritelmät dokumentissa käytetyille termeille. Luku 2 kuvaa sovelluskehikon toiminnan yleisellä tasolla. Sovelluskehikkoon liittyvät toiminnot, sen ympäristö ja käyttäjät esitellään lyhyesti. Luku 3 kuvaa sovelluskehikon tiedot. Ensimmäisessä kappaleessa kuvataan tietosisältö eli kuvataan tarkemmin käsitteet, jotka liittyvät sovelluskehikkoon toiminnallisen määrittelyn osalta. Lisäksi 3. luvussa käsitellään sovelluskehikon käyttöintensiteettiä ja kapasiteettivaatimuksia. Luvussa 4 määritellään sovelluskehikon toiminnot. Kustakin toiminnosta on kuvattu mitä se tarkoittaa, mitä se saa syötteeksensä ja toiminnon suorittamisesta tapahtuvat toiminnot ja/tai vaikutukset. Luku 5 kertoo sovelluskehikon ulkoiset liittymät, eli laitteiston, tietoliikenteen ja ohjelmistoliittyymät. Lukuun 6 on kuvattu järjestelmän ei-toiminnalliset ominaisuudet, kuten suorituskyky, vasteajat, käytettävyys ja ylläpidettävyys. TOIMINNALLINEN MÄÄRITTELY 5
Janne Kankaanpää 6 (6) Lukuun 7 on kirjattu suunnitteluun vaikuttavat rajoitteet, kuten standardit sekä ohjelmisto- ja laitteistorajoitteet. Luku 8 on varattu jatkokehitysajatuksille. TOIMINNALLINEN MÄÄRITTELY 6
Janne Kankaanpää 7 (7) 2 YLEISKUVAUS 2.1 Ympäristö Sovelluskehikko itsessään ei ole tuote, vaan se on tarkoitettu helpottamaan sovelluskehitystä ja tarjoamaan mallin, kuinka käyttöoikeuksia ja käyttäjätietoja voidaan hallita hajautetussa. Projektin lopputuote ei ole oikea tuote, vaan se on pikemminkin valmis Java API pakkaus, joka sisältää apuvälineitä Java-ohjelmointiin tietyn aiheen ympärillä. Sovelluskehikon toiminnallisuus otetaan käyttöön asiakkaan sovelluksia kehitettäessä tuomalla sovelluskehikko (Java: import) sitä hyödyntäviin luokkiin. 2.2 Toiminta Sovelluskehikolle voidaan määrittää kolme toimintoa: sovelluksen käyttäjän tunnistus ja todennus, käyttöoikeuksien kysyminen jostakin tietolähteestä (käyttöoikeuksien hallinta) sekä komentojen suorittaminen käyttöoikeuksia valvoen (komentojen reititys). Nämä toiminnot on selostettu tarkemmin luvussa 4. Sovelluskehikko tunnistaa ensin käyttäjän jonkun olemassaolevan tiedon perusteella ja todentaa sitten käyttäjän jossakin tietolähteessä olevan tiedon perusteella. Sen jälkeen, kun käyttäjä haluaa suorittaa komennon järjestelmässä, sovelluskehikko tarkastaa jälleen jostain tietolähteestä, onko käyttäjällä oikeus komennon suorittamiseen. Komento suoritetaan, jos käyttäjältä löytyi tarvittava oikeus. Sovelluskehikossa toteutettava komentorajapinta reitittää lisäksi käyttäjän komennon oikeaan kohteeseen ja palauttaa käyttäjälle vasteen, joka voi sisältää komennolle ominaisia tietoja. 2.3 Käyttäjät Sovelluskehikon käyttäjät ovat asiakkaan sovelluskehittäjiä (katso projektisuunnitelma [3]). Sovelluskehikosta on tarkoitus muodostua työkalu, jota voitaisiin käyttää mahdollisimman monissa asiakkaan projekteissa helpottamaan käyttäjien tunnistamiseen ja käyttöoikeuksien hallintaan liittyvää ohjelmointityötä. Sovelluskehikon metodikutsurajapinnan (katso luku 4.) avulla se voidaan liittää myös jo olemassaoleviin sovelluksiin. 2.4 Yleiset rajoitteet Sovelluskehikon tulee pitää käyttäjäoikeuksia sisältävät tiedot sisällään ja huolehtia ettei sessionumerointia voi spooffata. Suunnittelussa tulee noudataa J2EEspesifikaatiota. TOIMINNALLINEN MÄÄRITTELY 7
Janne Kankaanpää 8 (8) 3 Sovelluskehikon tiedot 3.1 Sovelluskehikon tietosisältö ja käsitteet Sovelluskehikko liittää todennettuihin käyttäjiin heidän käyttöoikeustietonsa. Käyttöoikeuksien toteutus riippuu toteutettavasta järjestelmästä, joten sovelluskehikon tulee olla laajennettavissa vastamaan tulevaisuuden tarpeita. Lisäksi se tarjoaa mallin, jolla selvitetään tavallisimmista tilanteista. käyttäjä N käyttää oikeus N palvelu Kuva 3.1: Käsitemalli Käyttäjään liittyy aina tietoja. Näitä voivat olla esimerkiksi:?? käyttäjätunnus tai muu yksilöivä tieto?? salasana?? nimi?? sähköpostiosoite?? puhelinnumero?? osoite?? tehtävä?? nimike?? julkiset ja salaiset avaimet Lista lienee loputon, joten käyttäjätietojen hallinnan on oltava laajennettavissa helposti. Lisäksi riippuen toteutettavasta sovelluksesta käyttäjällä on tietyt oikeudet sovellukseen. Nämä liittyvät aina tiettyyn toimintoon eli komentoon (Command). TOIMINNALLINEN MÄÄRITTELY 8
Janne Kankaanpää 9 (9) Käyttäjän käyttöoikeudet muodostavat käyttäjän kredentiaalit (Credentials). Kredentiaaleihin voi olla liitetty lipuke (Ticket), joka määrää ovatko kredentiaalit voimassa. Kredentiaalit sisältävät listan kaikista käyttäjän oikeuksista. Komentoa suoritettaessa käyttöoikeuksien lista tarkistetaan suoritettavaa toimintoa vastaan ja näin päätellään saadaanko operaatio suorittaa. Yksittäinen oikeus (permission) liittyy aina yhteen komentoon ja sillä voi olla lisäksi tyyppi sekä lipuke. Lipukkeet tarjoavat toiminnon, joka kertoo onko lipuke voimassa vai eikö. Lipukkeen voimassaololla voi olla päättymispäivämäärä, käyttökertojen määrä tai sen voimassaolo voidaan tarkistaa vaikka kolmannen osapuolen palvelusta. Lipukkeenkin tulee olla siis helposti laajennettavissa. Säännöt oikeuksien ja kredentiaalien voimassaolosta menevät seuraavasti:?? Jos kredentiaalin lipuke ei ole voimassa, mitkään oikeuksista eivät ole voimassa riippumatta oikeuksien lipukkeiden voimassaolosta.?? Jos kredentiaalin lipuke on voimassa, mutta oikeuden lipuke on vanhentunut, on kyseinen oikeus pois voimasta ja oikeuteen liittyvää toimintoa ei saada suorittaa. Samaa tietokantaa, joka voi olla esimerkiksi perinteinen relaatiotietokanta tai hakemistopalvelu, voivat käyttää muutkin sovellukset kuin sovelluskehikkoa hyödyntävä sovellus. Tämän vuoksi tiedot tulee tallentaa tietokantaan mahdollisimman selväkielisenä ja avoimesti. Serialisoidut luokat yms. Javaspesifiset toteutukset tulee sulkea pois lopullisessa toteutuksessa. 3.1.1 Käyttäjä?? edustaa sovelluksen käyttäjää. Käyttäjä voi olla reaalimaailman olento tai esimerkiksi toisen sovelluksen prosessi?? käyttäjällä on AINA yksilöivä tunniste. Tämä voi olla henkilötunnus, yrityksen sisäisesti käyttämä henkilönumero, käyttäjätunnus jne. Käyttäjään liittyvä tieto tulee olla merkitty TÄLLÄ tunnuksella.?? riippuen sovelluksesta käyttäjätietoihin kuuluu vaihteleva määrä tietoja. Näitä voivat olla esimerkiksi 1. salasana 2. nimi 3. sähköpostiosoite 4. puhelinnumero 5. osoite 6. tehtävä 7. nimike 8. avain (julkinen/salainen) 9. asiakasryhmä 10. ikä?? tietojen tallennuspaikka on sovelluskohtainen. Yhdessä sovelluksessa se voi olla relaatiotietokanta ja toisessa hakemistopalvelu. TOIMINNALLINEN MÄÄRITTELY 9
Janne Kankaanpää 10 (10) 3.1.2 Komento?? komento on operaatio tai toiminto, jonka käyttäjä voi suorittaa?? komento yksilöidään merkkijonolla, jonka tulisi kuvat sen luonnetta. Se voi olla vaikka CMD_SUORITA_XYZZY. Nimiä kuten CMD_A12G tulisi välttää.?? sovelluskehikko ei ota kantaa siihen, mitä toiminnot tekevät 3.1.3 Oikeus?? oikeus sallii jonkin komennon suorittamisen?? oikeudella voi olla myös tyyppi 1. luku 2. kirjoitus 3. poisto 4. lisäys 5. muu??? oikeuteen voi liittyä lipuke. Jos lipuke löytyy, tulee sen voimassaolo tarkistaa. 3.1.4 Kredentiaalit?? kredentiaalit on käyttäjätietojen osa, joka kuvaa käyttäjän turvallisuuden näkökulmasta, eli kredentiaalit sisältävät kaikki tarpeelliset tiedot käyttäjän oikeuksien tarkistamiseen sovelluksessa.?? kredentiaalit koostuvat joukosta oikeuksia sekä käyttäjän yksilöivästä tunnisteesta?? kredentiaaleihin voi liittyä lipuke. Jos lipuke on olemassa, tulee sen voimassaolo tarkistaa käyttöoikeuksia tarkistettaessa. Jos kredentiaalien lipuke ei ole voimassa, ei myöskään yksikään yksittäinen oikeus ole voimassa. 3.1.5 Lipuke?? lipuke on tiedonjyvänen, joka kertoo voimassaolosta. Lipukkeella on tila, joka kertoo, onko se voimassa vai ei. Lipuke on liitettävissä olioon, kuten käyttöoikeuteen, jolloin se määrittää kyseisen olion voimassaoloajan.?? voimassaolo voi määräytyä ajan, käyttökertojen tai jonkin muun tekijän mukaan 3.2 Käyttöintensiteetti Koska kyseessä on abstrakti sovelluskehikko, käyttäjämääriä ei voida suuremmin arvioida. Suunnittelussa tulee kuitenkin ottaa huomioon, että pääasiallinen käyttötarkoitus on hajautetut Web-pohjaiset sovellukset, joissa on pääsääntöisesti TOIMINNALLINEN MÄÄRITTELY 10
Janne Kankaanpää 11 (11) vähintään useita kymmeniä yhtäaikaisia käyttäjiä. Tämän vuoksi toteutuksen on skaalauduttava hyvin, eikä se saa hidastaa vasteaikoja LIIKAA. 3.3 Kapasiteettivaatimukset Sovelluskehikon ei tulisi asettaa kapasiteetille rajoituksia, vaan käytettävän kapasiteetin tulisi riippua pääasiassa käytettävien tietolähteiden ja sovelluspalvelimien kapasiteetista. TOIMINNALLINEN MÄÄRITTELY 11
Janne Kankaanpää 12 (12) 4 TOIMINNOT 4.1 Yleistä toiminnoista Sovelluskehikolla ei ole perinteistä käyttöliittymää, vaan sitä käytetään ohjelmoijan apuvälineenä tarjoamaan valmiiksi kehitetyt palvelut käyttäjien tunnistamiseen ja todentamiseen, sekä käyttöoikeuksien hallintaan. Nämä palvelut eivät ole riippuvaisia siitä, mitä käyttäjätietolähdettä käytetään, vaan sovelluskehikko voidaan rajapintojen kautta liittää useisiin eri tietolähteisiin. Näiden peruspalveluiden lisäksi tarjotaan valmiiksi toteutettuja toimintoja käyttäjien tunnistamiseen sovelluskehikon palveluita käyttäen www-selainkäyttöliittymälle. 4.2 Järjestelmän toiminnot Sovelluskehikko tarjoaa palvelunsa ohjelmoijalle kahden perusrajapinnan kautta. Nämä perusrajapinnat ovat:?? metodirajapinta?? komentorajapinta Ensimmäinen näistä on perinteinen metodirajapinta, jonka avulla sovelluskehikkoa voidaan käyttää metodikutsujen avulla. Tällöin ohjelmoija voi esimerkiksi kysellä sovelluskehikolta todennetun käyttäjän oikeuksia metodikutsujen avulla. Kuitenkin vastuu käyttöoikeuksien mukaisesta toiminnasta jää tällöin ohjelmoijalle. Metodikutsurajapinnan etuna on kuitenkin, että se on helpompi liittää vaikkapa olemassaolevaan sovellukseen. Komentorajapinta tarjoaa ohjelmoijalle kokonaisvaltaisemman ratkaisun, jossa käyttöoikeuksien hallinta pysyy sovelluskehikon sisällä. Tällöin ohjelmoija luo komento-olioita, jotka hän antaa sovelluskehikolle reititettäväksi komennon käsittelevälle oliolle. Komentoihin liitetään käyttäjän identiteettiä kuvaava olio, jonka perusteella sovelluskehikko tarkistaa, onko käyttäjällä oikeus komennon suorittamiseen. Komentorajapintaa käytettäessä ohjelmoija joutuu sitomaan sovelluksensa tiukemmin sovelluskehikkoon, ja joutuu esimerkiksi toteuttamaan sovelluksen toiminnot komentoina. Tällöin kuitenkin hyödynnetään sovelluskehikkoa parhaalla mahdollisella tavalla ja ohjelmoijalle jää vähemmän vastuuta oikeuksien tarkastamisessa eikä tietoa oikeuksista tarvitse siirtää kehikon ulkopuolelle. Sovelluskehikko tarjoaa seuraavat perustoiminnot: 1. todennus (metodirajapinta ja komentopalvelu) 2. Käyttöoikeuksien hallinta (metodirajapinta) 3. Komentojen reititys (komentopalvelu) Näiden perustoimintojen lisäksi sovelluskehikon mukana tarjotaan valmiiksi toteutettuna toiminnot käyttäjien tunnistamiseen ja todentamiseen selainkäyttöliittymän kautta käyttäjätunnuksen ja salasanan avulla. 4.2.1 Käyttäjien tunnistus ja todennus Sovelluskehikko tarjoaa palvelun käyttäjien tunnistamista ja todennusta varten sekä metodirajapinnan että komentopalvelun kautta. Idea käyttäjän tunnistamisessa on TOIMINNALLINEN MÄÄRITTELY 12
Janne Kankaanpää 13 (13) se, että jonkin käyttäjän välittämän tiedon perusteella tunnistetaan, kuka hän on ja todennuksen yhteydessä hän joutuu todistamaan olevansa se, kuka väittää olevansa. Esimerkkinä tästä voisi olla käyttäjätunnuksen ja salasanan avulla tapahtunut tunnistaminen ja todennus. Sovelluskehikko tarjoaa valmiiksi toteutettuna käyttäjätunnukseen ja salasanaan perustuvan tunnistamisen ja todennuksen, mutta sovelluskehikko suunnitellaan ja toteutetaan siten, että myös muita tapoja käyttäjän tunnistamiseen ja todentamiseen voidaan liittää siihen. Palvelu käyttäjien tunnistamiseen ja todentamiseen tarjotaan sekä metodirajapinnan että komentopalvelun kautta, mutta käyttötapa on erilainen. Metodirajapinta: Metodirajapinnan kautta käyttäjien todentaminen hoidetaan metodikutsun avulla. Koska sovelluskehikkoon on voitava lisätä eri tapoja toiminnon toteuttamiseen, toteutetaan niin kutsuttu factory-luokka, jonka tehtävänä on luoda haluttu rajapinta ohjelmoijalle.?? Ohjelmoija kutsuu factory-luokan metodia, joka palauttaa halutun rajapinnan käyttäjän tunnistamiseen ja todennukseen. Esimerkiksi: PasswordAuthentication auth = (PasswordAthentication)Authentication.getInstance( password );?? Rajapinnan saatuaan ohjelmoija kutsuu rajapinnan metodia, jolle hän antaa parametrina tunnistamiseen ja todennukseen tarvittavat tiedot. Esimerkiksi: auth.authenticate(userid, password);?? Metodi palauttaa onnistuneen kutsun tuloksena käyttäjän tiedot sisältävän olion tai null-arvon, mikäli käyttäjätunnus tai salasana oli virheellinen. Esimerkiksi: User user = (User)auth.authenticate(userId, password); Komentopalvelu: Komentopalvelua käytettäessä ohjelmoija ei suorita metodi-kutsuja, vaan hän luo komento-olion, ja antaa sen sovelluskehikolle. Uusille todennustavoille voidaan luoda uusia komento-olioita eikä metodirajapinnan tyyppinen factory-lähestymistapa ole tarpeellinen.?? Ohjelmoija luo komento-olion, johon hän asettaa tarvittavat tiedot. Esimerkiksi: PasswordAuthenticationCommand auth = (PasswordAuthenticationCommand)CommandFactory.createCommand( CM D_PASSWD_AUTH ); auth.setuserid(userid); auth.setpassword(password);?? Ohjelmoija antaa komento-olion sovelluskehikolle suoritettavaksi. Esimerkiksi: CommandManager.execute(auth);?? Sovelluskehikko palauttaa vastaus-olion, joka sisältää vastauksen komentoon. Mikäli käyttäjä tunnistettiin onnistuneesti, komento-olio sisältää käyttäjäolion käyttäjätietoineen. Esimerkiksi: PasswordAuthenticationResponse resp = CommanManager.execute(auth); User user = resp.getuser(); TOIMINNALLINEN MÄÄRITTELY 13
Janne Kankaanpää 14 (14) Huomioitavaa on, että käyttäjän oikeustietoja ei todennuksen yhteydessä palauteta, vaan käyttäjäolio sisältää salatun istuntokoodin, jonka avulla sovelluskehikko voi todeta, että käyttäjä on todennettu onnistuneesti ja istuntokoodin avulla käyttöoikeudet yhdistetään käyttäjään. Kuva 4.1: Tunnistaminen ja todentaminen 4.2.2 Käyttöoikeuksien hallinta Käyttöoikeuksien hallinta tarkoittaa tässä yhteydessä sitä, että kun käyttäjä sovelluksen kautta suorittaa toimintoja, tarkistetaan että hänellä on oikeudet toiminnon suorittamiseen. Tärkeää on, että voidaan varmasti todeta, että toimintoa suorittava käyttäjä on tunnistettu ja todennettu ja että hänen kredentiaalinsa sisältävät oikeuden toiminnon suorittamiseen. Tässä kohtaa sovelluskehikon toiminto poikkeaa riippuen käytetäänkö metodirajapintaa vai komentopalvelua. Metodirajapinta: TOIMINNALLINEN MÄÄRITTELY 14
Janne Kankaanpää 15 (15) Metodirajapintaa käytettäessä ohjelmoija ei joko halua sitoutua toimintojen suorittamiseen komentojen avulla tai se aiheuttaisi liikaa muutoksia olemassa olevaan sovellukseen. Tällöin sovelluskehikolla ei ole mahdollisuutta ottaa kantaa toimintojen suorittamiseen, vaan se voi ainoastaan kertoa minkälaiset oikeudet käyttäjällä on johonkin nimettyyn resurssiin. Esimerkki:?? Ohjelmoija kysyy käyttäjän käyttöoikeuksia metodikutsulla. Kutsulle annetaan parametrina resurssin nimi ja käyttäjäluokka, joka on saatu todennuksen yhteydessä. Sovelluskehikko varmistaa, että käyttäjä on todennettu tarkistamalla salatun istuntokoodin käyttäjäoliossa. Esimerkki: Permission perm = Authorisation. getpermission( RESOURCE_NAME, user); Tämän ohjelmoijan täytyy itse ohjelmassaan päättää, mitä saatujen oikeuksien perusteella tehdään. Komentopalvelu: Komentopalvelun yhteydessä käyttöoikeuksien hallinta tapahtuu automaattisesti. Käytettyihin komentoihin liitetään käyttäjän identiteettiä kuvaava olio. Sovelluskehikko tarkistaa reitittäessään komentoa kohteelleen, että käyttäjän oikeudet riittävät komennon suorittamiseen. Oikeudet tarkistetaan komento-olion sisältämän nimen perusteella. Mikäli käyttäjällä ei ole oikeuksia komennon reitittämiseen, heittää sovelluskehikko poikkeuksen (exception). Kuva 4.2: Käyttöoikeuksien hallinta TOIMINNALLINEN MÄÄRITTELY 15
Janne Kankaanpää 16 (16) 4.2.3 Komentojen reititys Komentojen reititys on palvelu, jota voidaan hyödyntää ainoastaan komentopalvelun kautta. Käyttäessään komentopalvelua ohjelmoija luo sovelluksensa toiminnoista komento-oliot (Command), joiden voisi ajatella vastaavan metodi-kutsun parametreja ja joihin myös liitetään käyttäjän identiteetin sisältävä olio. Komentojen suorituksesta vastaavat komentokohteet (CommandTarget), jotka komennon suoritettuaan palauttavat komentovasteen (Response). Sovelluskehikko toimii komennon ja sen kohteen välissä. Se reitittää komennon kohteelleen tarkastaen samalla että komennon suoritukseen liittyvä käyttäjä on tunistettu ja todennettu, ja että hänellä on oikeus suorittaa komento. Sovelluskehikko myös reitittää komentokohteelta tulevan vasteen komennon suorittajalle. Esimerkki: ListProductsCommand listprod = (ListProductsCommand)CommandFactory.createCommand( CMD_LIST_PROD ); listprod.setprincipal(user); listprod.setprice(40.50); ListProductsResponse resp = CommandManager.execute(listProd); Kuva 4.3: Komentojen reititys TOIMINNALLINEN MÄÄRITTELY 16
Janne Kankaanpää 17 (17) 4.2.4 Muut toiminnot Näiden perustavaa laatua olevien toimintojen lisäksi sovelluskehikon mukana tarjotaan valmiiksi toteutettuna käyttäjätunnuksen ja salasanan perusteella tapahtuva todennus ja tunnistaminen valmiiksi toteutettuna selainkäyttöliittymälle. Nämä toiminnot hyödyntävät sovelluskehikon tarjoamia peruspalveluita, joiden päälle toteutetaan käyttöliittymä ja käyttöliittymän parametrien tulkitsemisen toteuttava logiikka. Näiden palveluiden toteuttamiseen käytetään Java Servlettejä ja JSP:tä (Java Server Pages), joten ne vaativat toimiakseen sovelluspalvelimen, joka tukee JSDK 2.1- ja JSP 1.0-spesifikaatioita. HTML-lomakepohjainen tunnistaminen ja todennus HTML-lomakepohjainen tunnistaminen ja todennus tarjoaa HTML-lomakkeen, johon käyttäjä voi syöttää käyttäjätunnuksen ja salasanan. Lomakkeen ulkoasu toteutetaan HTML:llä ja lomakkeen parametrien tulkitsemiseen toteutetaan Servlet, joka käyttää sovelluskehikkoa käyttäjän todentamiseen. Mikäli kirjautuminen ei onnistu, näytetään käyttäjälle ilmoitus epäonnistumisesta. Onnistuneen tunnistamisen ja todentamisen yhteydessä käyttäjälle luodaan istunto ja hänet ohjataan ohjelmoijan haluamaan paikkaan sovelluksessa. Basic-tunnistaminen ja todennus Basic-tunnistamisen ja todennuksen yhteydessä käytetään HTTP-protokollaan liitettyä tunnistamis- ja todentamispalvelua. Käyttäjälle lähetetään HTTP-paketin otsikko-osassa tieto siitä että, hänen halutaan todentavan henkilöllisyytensä. Tämä aiheuttaa sen, että käyttäjän selain pyytää käyttäjältä näitä tietoja ja lähettää ne edelleen sovellukselle. Muuten toiminto toimii samalla tavalla kuin HTMLlomakepohjainen tunnistaminen. TOIMINNALLINEN MÄÄRITTELY 17
Janne Kankaanpää 18 (18) 5 ULKOISET LIITTYMÄT 5.1 Laitteistoliittymät Sovelluskehikon luonteesta johtuen tässä dokumentissa ei voida määrittää mitään siihen liiittyviä laitteistoja. Sovelluskehikko on käyttäjiensä työkalu, jota voidaan käyttää mitä erilaisimmissa projekteissa ja tilanteissa. Sovelluskehikkoon itseensä ei kuitenkaan suoranaisesti liity mitään käytetyistä laitteistoista riippuvaa toiminnallisuutta. 5.2 Ohjelmistoliittymät Sovelluskehikon täytyy olla geneerinen käytettävien tietolähteiden suhteen eli sovelluskehikon täytyy mahdollistaa minkä tahansa tietolähteen käyttö tervettä järkeä käyttäen. Käytännössä tämä toteutetaan siten, että sovelluskehikkoon liitetään sitä mukaan uusia rajapintoja eri tietolähteille, kun niille ilmenee tarvetta. Erilaiset tietolähderajapinnat ovatkin tärkeä osa sovelluskehikkoa. Alustavasti sovelluskehikolle toteutetaan tämän projektin puitteissa rajapinnat LDAP:iin (Lightweight Directory Access Protocol) ja IBM DB2:en. 5.3 Tietoliikenneliittymät Sovelluskehikon toteutuksessa ei oteta millään tavoin kantaa käytettäviin tietoliikenneyhteyksiin, kuten käytetäänkö modeemia, lähiverkkoa, tms. TOIMINNALLINEN MÄÄRITTELY 18
Janne Kankaanpää 19 (19) 6 MUUT OMINAISUUDET 6.1 Suorituskyky ja vasteajat Vasteaikoja ei voida sovelluskehikolle arvioida. Sovelluskehikko ei saa heikentää suorituskykyä LIIKAA. Mikä on liikaa, on sovelluskohtainen asia. 6.2 Turvallisuus ja suojaukset Turvallisuuden vuoksi tulisi käyttäjän kredentiaalit pitää sovelluskehikon sisällä. Metodirajapintakaan ei luovuta oikeuksia ulos sovelluskehikosta kuin yksittäistä oikeutta kysyessä. Turvallisuuden kannalta myös sovelluskehikon konfiguraatiotiedot ovat tärkeässä asemassa. Tämä ei kuitenkaan ole olennaista, vaan sovelluksen turvallisuudesta tulee huolehtia alemmalla tasolla sovelluspalvelimen asetuksilla. Jos murtautujalla on pääsy konfiguraatiotiedostoon, on hänellä samalla mahdollisuus muuttaa esimerkiksi sovelluksen luokkatiedostoja, jolloin on kaikki mahdollista. Sessionumeroita ei luovuteta sovelluskehikon ulkopuolelle huolehtimatta niiden eheydestä. Tämän vuoksi sessionumero tulee allekirjoittaa tai salata. 6.3 Ylläpidettävyys Sovelluskehikolle on erityisen tärkeää, että se on mahdollisimman ylläpidettävä. Sovelluskehikon on oltava hyvin geneerinen, jotta sen käyttö onnistuu erilaisissa sovelluksissa. Sovelluskehikkoon on voitava esimerkiksi liittää suhteellisen helposti uusia rajapintoja eri tietolähteisiin. Toteutuksen on tällöin oltava sellainen, että jo olemassaolevaan koodiin ei tarvitsisi tehdä juuri lainkaan muutoksia ja uutta koodia tarvitaan pelkästään uusiin rajapintaluokkiin. Sovelluskehikon toteuttamiseen käytetään J2EE:tä [4] (katso projektisuunnitelma, luku 8 [3]), josta on tällä hetkellä käytössä Java Development Kit:n versio 1.3. Tämä on yhteensopiva tulevien versioiden kanssa, joten käytettyjen JDK:n versioiden kanssa ei pitäisi ilmaantua hankaluuksia, kun sovelluskehikkoon tehdään myöhemmin muutoksia. 6.4 Siirrettävyys/kannettavuus, yhteensopivuus Sovelluskehikko toteutetaan kokonaan Javalla, joten se on laitteisto- ja ympäristöriippumaton. Sitä voidaan siis käyttää periaatteessa missä tahansa käyttöjärjestelmässä ja, jossa Javakin toimii. Sovelluskehikko ei tule valmiina viemään suurta levytilaa, sillä se sisältää pelkästään tavukoodia sekä lähdekoodia (ei kuvaa, ääntä tms.). Sovelluskehikon arvioitu levytilan tarve on maksimissaan ~1 Mt. Se on siten helposti siirrettävissä millä tavalla tahansa (verkko, disketti yms.) paikasta toiseen ja ottaa käyttöön ohjelmoinnissa. TOIMINNALLINEN MÄÄRITTELY 19
Janne Kankaanpää 20 (20) 6.5 Operointi Sovelluskehikon käyttäjät voivat sisällyttää niin halutessaan sovelluskehikkopakkauksen käyttämänsä koneen classpath-muuttujaan, jolloin sovelluskehikko on helpoiten käytettävissä. Tämä ei kuitenkaan ole välttämätöntä, jos sovelluskehikkoa halutaan käyttää aina erikseen, kun sitä tarvitaan.?? classpath-muuttuja on Java VM:n käyttämä ympäristömuuttuja, josta se hakee kääntämisen ja ajamisen aikana tarvitsemansa luokat.?? Esimerkki classpath-muuttujan asettamisesta: 1. Windows NT: set classpath=%classpath%; c:\ahma\ahma.jar; 2. Unix (C-shell): setenv CLASSPATH=$CLASSPATH: /lib/ahma/ahma.jar 3. Unix (Bourne-shell): export CLASSPATH=$CLASSPATH: /lib/ahma/ahma.jar Lisäksi tulee konfiguraatiotiedosto määritellä vastaamaan sovelluksen asetuksia. Tästä kirjoitetaan erillinen ohje. 7 SUUNNITTELURAJOITTEET 7.1 Standardit Projektiryhmä käyttää Sunin Java Code Convetionia Java-koodiin [5] (projektisuunnitelma, luku 11 [3]). Suunnittelussa tulee noudattaa J2EE-spesifikaatiota. 7.2 Laitteistorajoitteet Laitteistovaatimukset eivät ole merkittäviä. Projektin lopputuotteen peruspalveluiden käyttö ei aseta suuria vaatimuksia laitteistolle. Suurin osa asiakkaan kehitystyöstä tehdään tänä päivänä Windows NT 4.0, joten sitä voitaneen pitää suositusvaatimuksena. Kuitenkin myös esimerkiksi Windows 95:n vaatimukset riittävät mainiosti. Lopputuote ei vaadi levytilaa, joka merkitsisi tänä päivänä mitään (arvioituna enintään 1 Mt). Sovelluskehikko vaatii toimiakseen jonkin sovelluspalvelimen, kuten IBM WepSphere Application Server 3.5:n, jonka muistivaatimus on sovelluspalvelimelle vähintään 128 Mt, suositus kuitenkin 256 Mt. 8 JATKOKEHITYSAJATUKSIA Sovelluksen oikeuksien hallitsemista tulisi myös helpottaa. Tämän voisi toteuttaa Web-liittymällä käyttäjätietokantaan. Tällöin myös sovelluskehikon tulisi tarjota palveluita käyttäjätietojen muokkaukseen. TOIMINNALLINEN MÄÄRITTELY 20