3.1 Arkkitehtuurikaavio
| Päivä | Selitys | Tekijä |
|---|---|---|
| 24.11 | Taulukoitu funktioita | Timo,Mika,Teemu |
| 8.12 | Kasattu yhteen erikseen tehdyt osat | Teemu,Mika,Timo,Lauri |
| 14.2 | Sulautettu Käyttöliittymä (4.2) ja Ostoskori (4.3) toisiinsa, päivitetty 4.2:en oikeat servletin nimet, päivitetty 4.1. | Mika |
| 22.3 | Rakenne uudistettu, linkit erilliseen API-hakemistoon | Teemu,Mika,Timo,Lauri |
Teknisen määrittelyn aikana järjestelmän arkkitehtuuri on tarkentunut ja eri modulin rajapinnat on sovittu. Eri modulit on pilkottu itsenäisiin komponentteihin, joiden toiminta on määritelty. Ohjelmiston arkkitehtuuri onkin selkiytynyt varsin hyvin. Arkkitehtuurin suunnittelussa pysyttiin ennalta määritellyissä rakenteissa ja moduleissa. Luvussa 3.1 on toiminnallisesta kuvauksesta tarkentunut järjestelmän arkkitehtuurikaavio. Serverillä pyörivä sovellus on nimetty Application Serveriksi, jonka päällimmäisenä kerroksena on Servlet Interface. Tämän alta löytyy Business Services, tarjoaa Servlet Interfacelle tarvittavat palvelut. Business Services:n kuuluu myös Database Component, joka tarjoaa yhteydet allaoleviin tietokantoihin.
Servlet Interface (SI) on komponenti, joka pitää sisällään kaikki ulospäin näkyvät palvelut ja toiminnot. SI käyttää Business Services -komponentin palveluja, joiden avulla se muodostaa selaimelle tarvittavat HTML-sivut.
Business Services (BS) on komponentti, joka sisältää suurimman osan järjestelmän toiminnallisuudesta ja logiikasta. BS tarjoaa joukon Java-luokkia, joita Servlet Interface voi kutsua ja joista se löytää tarvitsemansa palvelut ostoskorin, asiakkaiden ja tilausten käsittelyyn.
Database Component (DBC) on komponentti, joka sisältyy Business Services -komponenttiin, ja jonka palveluita tämä käyttää. DBC:n tehtävä on tarjota abstrakti rajapinta tietokannan JDBC-yhteyksiä varten ja suorittaa tietokantaolioiden käyttämien kenttien nimien kytkeminen todellisiin tietokannan kenttiin.
Myös maksupalveluiden toiminta on selkitynyt. Luottokunnan tarjoaman palvelun toiminnan rakenne on teknisiltä yksityiskohdiltaan hyvin samanlainen pankkien vastaavien maksupalveluiden kanssa. Ainoana suurena erona pankkeihin on se että luottokunnan palvelu on käyttäjälle täysin näkymätön, kun taas pankkien palveluissa käyttäjä ohjataan pankkien sivuille suorittamaan maksun. Tällöin maksumoduliin on tehtävä lisäys: luottokorttia käytettäessä täytyy asiakkaalta kysy luottokortin numero, sekä voimassaoloaika, jonka jälkeen voidaan kyseinen lasku toimittaa luottokunnalle.
Ohjelmisto tarjoaa normaalin www-kaupan palvelut ostajalle: tuotteita voi selailla kategorioittain, tai hakea avainsanojen perusteella. Ostettavat tuotteet kerätään ostoskoriin. Ostokset voi maksaa suomalaisten pankkien elektronisella maksupalvelulla (esim. Meritan Solo) tai luottokortilla. Ulkomailla ohjelmistoa käytettäessä maksuliikenteestä vastaavan komponentin voi korvata paikallisella versiolla.
Ohjelmiston asennuksen yhteydessä kauppiaan olemassa olevat tietokannat kytketään järjestelmään, sekä muokataan käyttöliittymän ulkoasu imagon mukaiseksi. Varsinaista ylläpitotyötä järjestelmä ei vaadi.
Tärkein ominaisuus on siirrettävyys, ohjelmiston tulisi toimia mahdollisimman monelle palvelinalustalla sekä tukea mahdollisimman montaa tietokantaa. Näin ollen käytetään Javaa ja tietokantayhteyteen JDBC:tä erillisen rajapinnan kautta. Ohjelmointitapana käytetään Java Servlettejä. Ohjelman tulee myös olla modulaarinen, jotta em. maksukomponentin vaihto olisi mahdollista. Tavoitteena on, että varsinaisesta kaupasta (ostoskori) huolehtiva osa, maksuliikentekomponentti sekä tietokantarajapinta olisivat erillisiä komponentteja, jotka käyttävät toisiaan API:n kautta.
Järjestelmä konfiguroidaan käyttämään olemassaolevaan tietokantaan erillisellä asetustiedostolla, jolla määritellään linkki tietokantojen kenttien ja ohjelmiston käyttämien objektien välille. Tiedosto sisältää myös muita asetustietoja.
Application Serverin komponentti Business Services tarjoaa Servlet Interfacelle tarvittavan toiminnallisuuden kokoelmana Java-luokkina. Pääluokkiin kuuluu ostoskori, tuotteet ja tuotekategoriat, asiakkaat ja tilaukset. Lisäksi komponentti tarjoaa luokan asetusten lukemiseen. Asetukset toteutetaan sisäisesti Javan Properties-luokkaa käyttäen. Käytännössä asetukset sijaitsevat tiedostossa, ja asetusten avulla määritellään sovelluksen toimintaan vaikuttavia vakioita sekä tietokantayhteydet. Asetukset luetaan Properties-olioon sovelluksen käynnistämisen yhteydessä. Business Services -komponenttiin kuuluu myös sisäinen komponentti Database Component, joka mahdollistaa yhteydet tietokantaan. Komponentin luokat muistuttavat Javan luokkia (paketista java.sql), joiden avulla JDBC-yhteydet tietokantoihin on toteutettu. Sisäisesti komponentti käyttääkin näitä Java-luokkia, mutta toimii samanaikaisesti wrapperina JDBC-luokille kätkien ne sisäänsä ja tarjoten lisäpalveluita, erityisesti loogisten tietokantanimien (taulut ja tietueiden kentät) kytkemisen todellisiin SQL-tietokannan nimiin. Näin Database Componentin käyttäjän ei tarvitse tietää mitään tietokannan sisäisestä rakenteesta.
Pankkien tarjoamat maksupalvelut mahdollistavat ostoksien maksamisen Internet selaimen avulla. Maksamisessa on kolme eri vaihetta.
Asiakkaan ja pankin sekä asiakkaan ja kauppaa harjoittavan yrityksen välinen tietoliikenne suojataan SSL-tekniikka käyttäen. Tämä edellyttää että asiakkaalla on käytössä selain, joka tukee SSL-tekniikkaa. Esimerkiksi Netscape Navigator 4.0 ja Internet Explorer 4.0 sarjan selaimissa sekä uudemissa on tämä tuki.
Eri pankkien maksupalveluiden toteutukset eroavat toisistaan hyvin vähän. Pääasiassa muuttuu vain toimitettavien kenttien nimet. Seuraavassa on lueteltu tärkeimmät kentät.
Lasku muodostetaan HTML-dokumentiksi, jossa on halutun nimisissä kentissä tarvittava tieto. Tämä dokumentti lähetetään pankin maksujärjestelmille POST-metodilla. Kun asiakas on siirtynyt pankin maksujärjestelmiin, käyttää hän pankin hänelle antamia tunnuksia laskun maksamiseen.
Turvatarkiste on SSL-tekniikasta lisäksi tuleva varmistus, jolla pyritään varmistaan maksun oikeellisuus. Pankkien maksupalveluissa ominaisuus on valinnainen, luottokunnalla pakollinen. Turvatarkiste luodaan yhdistämällä maksussa olevien kenttien sisältö sekä myyjäkohtainen, salainen avain yhdeksi merkkijonoksi. Tälle merkkijonolle suoritetaan MD5-algoritmilla hash-arvo, joka liitetään mukaan laskuun.
Kun asiakas on suorittanut maksun ja hän palaa takaisin myyjän sivuille, voidaan pankkien maksupalveluja käytettäessä lisätä linkin perään laskun tiedoista ja myyjän avaimesta laskettava turvatarkiste, jonka avulla myyjä voi varmistua siitä että lasku on todella maksettu.
Lisäksi ainakin Leonia tarjoaa palvelun, jossa voi HTTP(S)-protokollaa käyttäen kysellä maksujen onnistusta erikseen.
Luottokunta MIA-palvelu eroaa pankkien palvelusta teknisiltä ratkaisultaan varsin vähän. Käyttäjälle näkyvin ero on siinä että maksumodulin on itse kysyttävä luottokortin numero ja voimassaoloaika, kun pankin järjestelmissä käyttäjä ohjataan pankin omille sivuille täyttämään tunnusnumeroita ja maksamaan laskua. Luottokunnan palvelu onkin käyttjälle täysin nykymätön. Asiakas ei missään vaiheessa siirry luottokunnan sivuille, vaikka käyttääkin palvelua. Asiakkaan antamat luottokortin tiedot lähetetään luottokunnan serverille POST-metodilla ja paluu URL muodostuu sen mukaan onnistuiko maksu vai ei.
Luottokortissa lähetetään luottokunnalle pankkien maksupalveluissa olevien kenttien lisäksi luottokortin numero sekä voimassaoloaika, joiden perusteella maksu suoritetaan.
Luottokunnan palvelussa maksun onnistumista ei saa tietää paluu URL:ssä, kuten pankeilla, vaan maksun onnistumista voi kysellä erillisen status-kyselyn avulla. Kyselyssä lähetetään luottokunnan palvelimelle HTTP(S)-protokollan mukainen kysely, jossa on tietyt kentät sekä näistä laskettu MAC-tarkiste. Jos tarkiste täsmää, saadaan takaisin tietyn muotoinen tekstitiedosto, jossa on mm. maksun tila.
Tietoturvan kannalta merkittävin ero maksupalveluihin verrattuna on se että luottokortilla maksettaessa asiakas syöttää luottokortin numeron sekä voimassaoloajan tunnuksien sijaan. Koska nämä tiedot pysyvät eri maksukerroilla samoina, on luottokunnan maksupalvelu teoriassa haavoittuvampi mahdollisille huijausyrityksille. Käytännössä luottokunnan maksupalvelun turvallisuus perustuu SSL-salaukseen sekä MD5-algoritmillä tehtävään varmisteeseen, jotka yhdessä pystyvät varmistamaan maksun oikeellisuuden.
Java Servlet Engine pitää yllä sessiotietoja. Jokainen
käyttäjä saa tullessaan jollekin kaupan sivulle oman session.
Käyttäjät (ja heidän sessionsa) tunnistetaan cookieden
perusteella, eli käyttäjän täytyy sallia cookieiden
käyttö selaimessaan. Ohjelma on mahdollista rakentaa toimimaan
ilman cookieita, jolloin tunnistus tapahtuu enkoodattujen requestien (URL:ien)
perusteella. Session voimassaoloaika määritellään JSE:en
omissa asetuksissa käynnistettäessä, mutta sitä voi
muuttaa myös servleteistä.
Sessio-objektiin tallennetaan objekteina ostajan ostoskorin sisältö.
Mikäli käyttäjä kirjautuisi aluksi kauppajärjestelmään
sisään, sessioon voitaisiin tallentaa esim. käyttäjäkohtaiset
alennusprosentit tuotteista.
Lisäksi JSE:llä voi olla muistissa koko palvelimeen liittyviä
objekteja. Nopeuden lisäämiseksi kaikki tuotekategoriat
sisältävä objekti säilytetään tällä
tavalla.
servlet Interface (DBC) tuottaa ohjelman käyttöliittymän käyttäen Business Services -komponentin palveluja. Ulkoasu määritellään templateilla, joiden muokkaamisesta on tehty erillinen ohje.
Database Component (DBC) on komponentti, joka sisältyy Business Services -komponenttiin, ja jonka palveluita tämä käyttää. DBC:n tehtävä on tarjota abstrakti rajapinta tietokannan JDBC-yhteyksiä varten ja suorittaa tietokantaolioiden käyttämien kenttien nimien kytkeminen todellisiin tietokannan kenttiin.
Business Services (BS) on komponentti, joka sisältää suurimman osan järjestelmän toiminnallisuudesta ja logiikasta. BS tarjoaa joukon Java-luokkia, joita Servlet Interface voi kutsua ja joista se löytää tarvitsemansa palvelut ostoskorin, asiakkaiden ja tilausten käsittelyyn.