Teksti suurus

Reavahe

Kontrastsus
Seaded

 

Riigiportaali tehnoloogilise raamistiku täiendamise hankedokumendi küsimused-vastused

 Riigiportaali tehnoloogilise raamistiku täiendamise hankedokumendi kohta on saabunus alljärgnevad küsimused:

1.  Küsimus (saabunud 09.11.2009): Kas JAVA-arhitektuuri rakendusserveris nähakse pigem nii, et gateway on üks JAVA servlet, mis vastavalt seadistatud reeglitele suunab http-päringu töötlemise edasi mõnele teisele vastavale servletile või pigem on soov siiski luua ühte ja kompaktne servlet-teenus, mille „esimene moodul“ on gateway ning mis vastavalt http-päringule dünaamiliselt kutsub välja vajalikke liidestatud teenuseid, mis omakorda kasutavad loodavat JAVA „põhimoodulit“, mis pakub portaali tööks valikke põhifunktsionaalsusi (õigused, sessioon jne)?
 
Vastus (avaldatud 10.11.2009):  Gateway võiks olla eraldiseisev Java rakendus, mis teenindab ainult PostgreSQL raamistikule suunatud päringud. Näiteks praegune Gateway on väljakutsutud veebiserveriga www.eesti.ee/portaal/* URL’ide puhul. Inimloetavad url’id teisendatakse samuti veebiserveri poolt www.eesti.ee/portaal/* kujule („Rewrite“ reeglite abil). Näiteks www.eesti.ee/est/teemad/turvalisus/ on teisendatud kujule: www.eesti.ee/portaal/!portaal.clean_url?%2Fest%2Fteemad%2Fturvalisus%2F .
Kõik üldkasutatavad komponendid nagu andmebaasi liigipääs, sessiooni andmete üleandmine, õiguste funktsionaalsus, muud abifunktsioonid jne võiks tõsta „Java moodulisse“, ülejäänud funktsionaalsus peaks olema Gateway sees. Teised Java rakendused võivad samuti kasutada seda „Java moodulit“, kui neil on vajadus suhelda PostreSQL raamistikus olevate rakendustega.
 
2. Küsimus (saabunud 09.11.2009): Java loodav moodul peab looma arendajatele efektiivselt kasutatavad tehnilised vahendid, mis võimaldavad ära; kasutada olemasolevaid kasulikke mooduleid/meetodeid tänastest Postgres asuvatest baasifunktsioonidest. Kas on vaja luua ka vastupidine võimalus, kus näiteks mõni süsteemi tööks oluline komponent realiseeritakse JAVA teenuse/meetodina ning seda peaksid saama kasutama hakata „vanad“ Postgre rakendused? Näiteks juhul, kui mõni portaali töös keskset rolli täitev funktsionaalsus luuakse JAVAs ning portaali halduse lihtsuse mõttes oleks mõistlik senised Postgre analoogsed funtsioonid asendada vastavate JAVA protseduuride väljakutsetega (vähendamaks andmebaasiserveri koormust ning samas tagades vanade rakenduste töö jätkusuutlikkuse).
 
Vastus (avaldatud 10.11.2009): PostgreSQL rakenduste liigipääs Java üldkasutatavale funktsioonidele oleks meile väga kasulik ning me loeks seda kasuliku lisaväärtusena (vaata hindamiskriteeriumid HD 5.2.2.4). Hankedokumendis on selle kohta kirjutatud: „Tagada võimalus tulevikus üle viia Riigiportaali üldkasutatavad komponendid (näiteks Riigiportaali päised ning menüüd) Java keelde parema jõudluse tagamiseks.“
Kuna hankijal praegusel hetkel puudub selge ettekujutus,kuidas oleks võimalik efektiivselt realiseerida vastust tagastavate Java funktsioonide väljakutsed, siis me ei ole seda otseselt nõudnud. Vastust mittetagastavate funktsioonide väljakutsumine on meie miinimumnõue (Näiteks päiste ning menüü plokkide väljastamist oleks võimalik realiseerida nii, et Gateway töötleks PostgreSQL rakendusega tagastatud vastust ning asendaks kindlad märgendid Java abifunktsioonide väljundiga).
 
3. Küsimus (saabunud 09.11.2009): Hankedokumentides kirjeldatakse nõudeid loodava gateway kiiruslike omaduste kohta kui „mitte halvemaid kui tänasel gateway-l“. Kas RIA on kogunud hankedokumentides mainitud JMeter testide vastavad tänased näitajad ning kas neid andmeid saaks avalikustada pakkujatele? Kas arendajatele võimaldatsakse juurutuskeskkonnas piisav ligipääs RIA tehnilistele ressurssidele, et neid teste võrdsetes tehnilistes keskkondades uuele gatewayle rakendada?
 
Vastus (avaldatud 10.11.2009): Antud nõue on kirjeldatud selleks, et uue Gateway’ga kasutajaliidese genereerimise kiirus jääks vähemalt samaks. Praegusel hetkel ei ole hankija mõõtnud portaali kiirust, kuid pakkujad võivad teha seda ise. Lihtsamate testide jaoks (nagu esilehe kiiruse mõõtmine) ei ole ilmselt vajadust omada erilist liigipääsu. Ning keerulisemate testide läbiviimiseks saab luua väikesed abifunktsioonid, mida oleks võimalik käivitada ka toodangu keskkonnas.

4. Küsimus/ kommentaar (saabunud 09.11.2009): Üks analüüsi huvitavaid küsimusi saab olema, kuidas ehitada üles gateway teenuste adresseerimissüsteem. Arvestades inimloetavate URLide kasutamist, tuleb see info ju andmebaasist. Samas ei tohiks gateway olla ehitatud arhitektuurselt selliselt, et andmebaasi mitte-töötamise korral ei suuda gateway midagi mõistliku peale „general error“i tagastada. Eriti kui tegelik realiseeriv teenus on JAVA teenus, võib osutuda mingil puhul andmebaasiühenduse puudumine mittevajalikuks, kuid igal juhul saaks vastav JAVA rakendus väljastada kasutajale palju adekvaatsema veateate. Ilmselt on mõistlik vastavat adresseerimisinfot gateway poolel kuidagi mõistlikul cacheda...
 
Vastus (avaldatud 10.11.2009): Adresseerimissüsteemi võiks korraldada nii, et Gateway töötleks URL’id kujul /portaal/*, ning inimloetavate URL’ide puhul toimuks URL’ide teisendamine /portaal/* kujule (näiteks veebiserveri „Rewrite“ reeglite abil). Näiteks www.eesti.ee/est/teemad/turvalisus/ võiks olla teisendatud kujule: www.eesti.ee/portaal/!portaal.clean_url?%2Fest%2Fteemad%2Fturvalisus%2F. Teised Java rakendused, mis ei ole otseselt PostgreSQL raamistikuga seotud võiksid kasutada URL’e kujul /muurakendus1/*, /muurakendus2/* jne. Kui arendaja arvates see süsteem ei sobi, siis võib ta pakkuda ka muud lahendust, kuid tuleb arvestada sellega, et kõik olemasolevad URL’id peavad töötama ka uue Gateway’ga (hetkel portaalis on kasutatud URL’id kujul /portaal/*, /est/*, /rus/*, /eng/* ). Juhul, kui tegemist on PostgreSQL raamistikul realiseeritud funktsiooniga, siis on loomulik, et Gateway oskab tagastada ainult „General Error“ ning teised rakendusserveris asuvad Java rakendused oleks võimelised tagastama veateated ise.
 
5. Küsimus (saabunud 10.11.2009): Kas ka ID-kaardiga sisselogimine (http://www.eesti.ee/login/index.php) tuleb viia Java keskkonda? Pangalingi kaudu autentimisega seda probleemi vist ei tohiks olla, kuna see toimib HTTP tasemel ja olemasoleva Postgresis realiseeritud funktsionaalsuse saab säilitada.
 
Vastus (avaldatud 10.11.2009):  Kuna primaarne sessioon peaks olema Java rakendusserveris, siis nii kui nii tuleks realiseerida Pangalingist tulnud sessiooni andmete üleandmist Java rakendusserverisse. Sama funktsionaalsus võib olla kasutatud ka ID-kardiga sisselogimisel. Samas parem oleks realiseerida ID-kardiga sisselogimist Java’s. Kuna hankijal olid plaanid lähiajal kaotada PHP’s tehtud ID-kardiga sisselogimine, siis Java’s realiseeritud sisselogimine annaks meile lisaväärtuse. Pangalingi funktsionaalsus oleks tõesti otstarbekas säilitada.
 

6. Küsimus (saabunud 10.11.2009): Kas Java näidisrakenduse loomisel tuleb välja pakkuda ka raamistik, mille alusel edaspidi Java rakendusi eesti.ee keskkonnas looma hakatakse? Kas on selles osas eelistusi, nt mingite vabavaraliste raamistike suhtes (nt Tapestry, Cocoon, JSF, Spring, Struts, Aranea, ...)? Kõik tulevased Java rakendused ei hakka ju olema WSRP portletid?
 
Vastus (avaldatud 10.11.2009):   Gateway nagu ka näidisrakendus on rakendusserveri jaoks samaväärsed servletid, mis omakorda kasutavad „Java moodulit“, mis korraldab suhtlemist andmebaasiga. Seoses sellega oleks otstarbekas et Gateway, näidisrakendus ning „Java moodul“ kasutaks sama Java raamistiku. Kõik tulevased rakendused tõepoolest ei hakka olema WSRP portletid, ning seoses sellega raamistik peaks olema vabavaraline, hea funktsionaalsusega, ning Eestis levinud. 
 
7. Küsimus (saabunud 10.11.2009): Kas saaksite täpsustada, mida ootab hankija pakkumusest seoses eskiislahenduse punkti 1.1.3 ja selle alampunktidega? Kinnitust, et sellised dokumendid on plaanis koostada, koos lühida struktuuri/sisukirjeldusega dokumentide kaupa?

Vastus (avaldatud 12.11.2009): Järgnevalt on toodud dokumentide sisukirjeldused:

1. Süsteemi üldine kirjeldus
Otstarve: Anda üldine ülevaade kogu süsteemist.
Sisu: Kirjeldus süsteemi sihtrühmast, kasutamise eesmärgist ja haldamiseks vajaminevast kompetentsist.
Koostaja: arendaja
Sihtgrupp: administraatorid, tootejuhid

2. Süsteemi tehniline spetsifikatsioon
Otstarve: Kirjeldab üleantavata süsteemi, seadmete ja kommunikatsioonide funktsionaalsust ning tehnilisi parameetreid.
Sisu: Spetsifikatsioon peab rahuldama vähemalt alljärgnevaid sisunõudeid:
Serverite ja kliendipoolsete seadmete soovituslikud parameetrid
Kommunikatsioonide soovituslikud parameetrid (andmesidekiirused, võimsused, jms)Installeerimisprotseduurid
Kõik nõuded peavad olema kooskõlas kehtivate standarditega.
Koostaja: arendaja
Sihtgrupp: administraatorid

3. Taasteplaan
Otstarve: Tagada peale hävingut süsteemi kiire ja tõrgeteta taastamise.
Sisu: Taasteplaan on aluseks süsteemi taastamiseks peale suuremat hävingut. Kuna andmekiht jääb antud süsteemi skoobist välja, siis tegemist on süsteemi taaskäivitamise juhendiga.
Koostaja: arendaja koostöös administraatoritega.
Sihtgrupp: administraatorid

4. Riskianalüüs
Otstarve: Välja tuua infosüsteemi võimalikud kitsaskohad.
Sisu: Süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus.
Koostaja: arendaja koostöös administraatoritega.
Sihtgrupp: administraatorid, kasutajatugi

5. Administreerimisjuhend
Otstarve: Juhendid on aluseks süsteemi administreerimisel ja kasutamisel.
Sisu: Administreerimisjuhend peab rahuldama vähemalt alljärgnevaid sisunõudeid:
* Süsteemi parameetrite kirjeldus ja nende muutmiste mõjud ja protseduurid
* Tarkvara funktsionaalsuse kirjeldus
* Rutiinsete hooldusprotseduuride kirjeldus
Koostaja: arendaja
Sihtgrupp: tootejuhid, administraatorid

6. Kasutajajuhend (arendajatele mõeldud juhend)
Otstarve: Arendajatele mõeldud juhend.
Sisu: Arendajatele mõeldud juhend jätkuarenduste läbiviimiseks ning „Java mooduli“ kasutatavate rakenduste loomiseks.
Koostaja: arendaja
Sihtgrupp: tulevased arendajad

7. Testide dokumentatsioon
Otstarve: Testide dokumentatsioon on vajalik süsteemi vigade väljaselgitamiseks.
Sisu: Dokumenteeritakse eesmärgid, tegevused ja tulemused igal testimisel.
Koostaja: arendaja, projektijuht, tootejuht
Sihtgrupp: vastuvõtutesti läbiviijad

8. Versioonihalduse dokumentatsioon
Otstarve: Vajalik ülevaate saamiseks infosüsteemi versioonide muudatustest.
Sisu: Detailne info iga versiooniuuenduse kohta – kuna tehti, milline versioon, millised muudatused.
Koostaja: arendaja
Sihtgrupp: tootejuhid

Lisatud 30.03.2012

Tagasi lehele "Riigihanked"