THL.fi-portaalin tekninen arvio

Transkriptio

1 THL.fi-portaalin tekninen arvio Jussi Kurki

2 THL.fi-portaalin tekninen arvio Tiivistelmä Mikä on hyvin? Mikä on huonosti? Miten ratkaistaan? Johdanto Nykyisen ratkaisun vahvuuksia Keskeiset ongelmat Teknisen toteutuksen kuvaus Alfresco ja Liferay Keskeiset räätälöidyt komponentit Järjestelmän arvionti Ohjelmakoodin staattinen analyysi Testit Kuormitustestaus Ratkaisuehdotuksia Vanhan järjestelmän korjaaminen Uusi räätälöity sivusto Liferay Liferay ja Alfresco Drupal Plone

3 Yhteenveto

4 Tiivistelmä Resurssien puutteen, toteuttajien heikon osaamisen ja epäonnistuneen valvonnan seurauksena syntynyt sekava ja epäluotettava organisaatiosivusto turhauttaa sekä sivuston käyttäjiä, ylläpitäjiä että kehittäjiä. Laitoksen maine kärsii huonosta julkisivusta eikä järjestelmä takaa kriisivalmiutta. Mikä on hyvin? 1. Sivusto on käytössä 2. Valitut teknologiat oikein käytettyinä pystyisivät suuren kuormaan 3. Osaamiseen ja teknologiaan on investoitu THL:ssä 4. Järjestelmän suunnitteluperiaatteet ovat olleet hyvät Mikä on huonosti? THL.fi:tä varten suunniteltu ja toteutettu ratkaisu on tarpeettoman monimutkainen. Työssä ei ole hyödynnetty jo olemassa olevia palveluita vaan niitä on joko toteutettu uudestaan tai räätälöity, sillä toteuttajat eivät ole osanneet käyttää valitsemiansa komponentteja täysimääräisesti. Tarpeeton monimutkaisuus näkyy erityisesti toteutuksen heikossa laadussa. Toteuttajilla on kulunut aikaa ja resursseja pyörän uudelleen keksimiseen sen sijaan, että he olisivat keskittyneet toteuttamaan THL.fille lisäarvoa tuottavia ominaisuuksia. Tästä seurannut ylimääräinen kiire on kannustanut menemään sieltä, mistä aita näyttää matalimmalta. Tällöin toteutuksen laatutekijät ovat kärsineet. Merkittävimmät ongelmat ovat palvelun saatavuudessa ja käytettävyydessä. Järjestelmä ei pysty palvelemaan kuin noin samanaikaista käyttäjää. Lisäksi palvelu kaatuu viikottain ilman selkeää syytä. Käytettävyysongelmat sivustolla ja ylläpitokäyttöliittymässä heijastuvat negatiivisena käyttäjäpalautteena ja verkkopäivittäjien turhautumisena. Miten ratkaistaan? Keskeisin kysymys on halutaanko räätälöity uudenaikainen organisaatiosivusto, vai tyydytäänkö valmiiseen pakettiratkaisuun, jota räätälöidään vain tarpeen mukaan. Teknisestä näkökulmasta ensimmäistä vaihtoehtoa voi lähestyä 1) yrittämällä korjata nykyistä järjestelmää tai 2) aloittamalla samankaltaisen projekti uudestaan. Pakettiratkaisussa vaihtoehtoina on ottaa käyttöön jokin nykyisistä markkinoilla olevista sisällönhallintajärjestelmistä, joka täyttää sivuston perustarpeet ilman räätälöintejä.

5 Johdanto Terveyden ja hyvinvoinnin laitoksen verkkosivustoa on kehitetty laitoksen perustamisesta alkaen, aluksi kiireellä, loppua kohti takuukorjauksin. Sivuston pohjana toimii Tervesuomiprojektissa 1 kehitetty tietomalli ja sen portaalitoteutus. Yhteisellä alustalla on haettu synergiaetujen lisäksi älykkäitä haku- ja aihenosto-ominaisuuksia. Sivuston teknisen toteutuksen on tehnyt Proactum/Priorite. THL.fi-portaalia suunniteltaessa on laadittu lista hyvistä toteutusperiaatteista. Seuraavassa joitakin poimintoja projektin arkkitehtuuridokumentaatiosta. Järjestelmä rakennetaan kerrosrakenteisesti siten, että riippuvuudet ovat yksisuuntaisia Itse kirjoitettu koodi ja alusta pyritään erottamaan selvästi toisistaan Virhekäsittelyssä kaikki virheet otetaan kiinni ja vähintäänkin kirjoitetaan logiin Käytetään automaattista yksikkötestausta helpottamaan regressiotestausta Nämä periaatteet on kenen tahansa ohjelmistosuunnittelijan helppo allekirjoittaa. Näitä kaikkia myös rikotaan THL.fi:n toteutuksessa. Sivuston käytettävyydessä ja teknisessä toteutuksessa on ilmennyt vakavia ongelmia, jonka takia sivuston konsepti ja tekninen toteutus on päätetty uudelleenarvioida. Tässä dokumentissa esitellään teknisen toteutuksen keskeiset ongelmat. 1 Tervesuomi.fi on THL:n kehittämä kansalaisille suunnattu verkkopalvelu, jossa tarkoituksena on esittää eri lähteistä kerättyä aineistoa yhdenmukaisen käyttöliittymän kautta. Palvelua on kehitetty yhdessä Aalto yliopiston Semanttisen laskennan tutkimusryhmän (SeCo) kanssa ja metatietomalli pohjaa semanttisen webin periaatteisiin (esim. jaetut sanastot ja ontologiat).

6 Nykyisen ratkaisun vahvuuksia Järjestelmä on olemassa ja sen avulla voidaan julkaista perussisältöä. Vaikka järjestelmässä on runsaasti puutteita, on se parempi kuin yhdistelmä vanhojen organisaatioiden sivuja. Arkkitehtuuridokumenteissa määritellyt periaatteet mukailevat hyviä ohjelmistosuunnitellut periaatteita. Periaatteiden mukaisesti projekti sisältää testejä, on modulaarinen ja hyödyntää hyväksi havaittuja valmiita kirjastoja. (Periaatteita on kuitenkin useassa kohtaa laiminlyöty.) Järjestelmän käyttäminen ja siihen tutustuminen on kartuttanut talon sisäistä osaamista ja tuonut kokemusta useista eri alustoista ja tekniikoista.

7 Keskeiset ongelmat Sivuston pohjana toimii Alfresco-sisällönhallintajärjestelmä ja Liferay-portaalialusta. Molemmat ovat paljon käytettyjä ja hyvinä pidettyjä. Järjestelmät ovat kuitenkin raskaita työkaluja yksinkertaiseen ongelmaan. Tämänhetkisen tilanteen, kohtalaisen pienen kokoelman käsinsyötettyä sisältöä, saisi toteutettua huomattavasti yksinkertaisemmalla ratkaisulla. Alfrescon ja Liferayn päällä on Proactumin kehittämä alusta (Proactum Enterprise Platform), joka sisältää projektien hallintaa ja konfiguraatiota sekä dynaamisesti ladattavien skirptiportlettien toteutuksen. Alustan heikkoutena on monimutkaisuus ja turha riippuvuus Proactumin palvelimista ja koodista. Alfrescon ja Liferayn muuttaminen estää niiden päivittämisen. Toteutuksessa on räätälöity mm. Alfrescon indeksointitoteutusta, mikä estää järjestelmän suoraviivaisen päivittämisen. Päivitysten hankaluus on myös tietoturvariski. Alfresco ja Lifearay ovat riippuvaisia toisistaan. Räätälöidyistä portleteista kutsutaan suoraan Alfresco-olioita. Huono suunnittelupäätös aiheuttaa hitautta ja tekee testaamisesta hankalaa. Lisäksi sisällönhallintajärjestelmän tai portaalitoteuksen vaihtaminen on erittäin hankalaa. Alfrescon ja Liferayn välille on rakennettu epästandardi Javan etämetodikutsuihin (RMI) perustuva silta. Alfrescon ja Liferayn integrointi on tunnetusti hankalaa, mutta esimerkiksi valmiit REST- tai Web service -rajapinnat olisivat tarjonneet parempia lähestymistapoja. Koodin laatu heikkoa. Järjestelmässä on kymmeniä kriittisiä virheitä ja satoja pieniä virheitä sekä tuhansia tyylillisiä rikkeitä. Koodin seassa on paljon poiskommentoitua koodia, käyttämättömiä import-lauseita, tyypittömiä tietorakenteita (ei käytetty Javan genericsominaisuuksia). Tämä tekee koodista epäluotettavaa ja hankalasti jatkokehitettävää. Projektin testit ovat puutteellisia. Joissakin moduleissa ei ole lainkaan yksikkötestejä. Integraatiotestit kestävät yli tunnin ja tulokset vaihtelevat eri ajoissa. Monimutkaisen projektin jatkokehitys ilman kunnollisia testejä on hankalaa. Koodi ei skaalaudu suurille käyttäjämäärille. Kuormitustestauksessa testiympäristö skaalautui noin 50 samanaikaiselle käyttäjälle. Vaikka tuotantoympäristö on tehokkaampi, on raja todella alhainen Liferayn oletusasennuksen skaalautuessa noin 1000 käyttäjään. Ylläpitokäyttöliittymä ja THL.fi eivät ole käytettäviä. Käyttäjä joutuu usein THL.fi:stä yllättäen toisiin palveluihin, sillä toteutus on monilta osin jäänyt keskeneräiseksi. Ylläpitokäyttöliittymä aiheuttaa käyttäjille ongelmia ja esimerkiksi dokumenttien lukitusperiaatteet on vaikeasti ymmärrettävissä.

8 Teknisen toteutuksen kuvaus Alfresco ja Liferay THL.fi rakentuu kahdesta valmiista pääkomponentista: Alfresco-sisällönhallintajärjestelmästä ja Liferay-portaalialustasta. Molemmat ovat avoimeen lähdekoodiin perustuvia Java-pohjaisia järjestelmiä, joista on saatavilla sekä ilmaiset että maksulliset versiot haluttujen ominaisuuksien ja tuen mukaan. Alfrescosta on käytössä maksullinen versio (n euroa vuodessa), Liferay-alustasta käytössä on ilmainen versio. Alfresco on sisällönhallintajärjestelmä, joka on suunniteltu suurten dokumenttikokoelmien hallintaan. Dokumenttiin voidaan liittää mielivaltaisia metatietoja ja dokumentin elinkaarta voidaan hallita erilaisten tilojen avulla (esimerkiksi vedos, odottaa hyväksyntää, hyväksytty ja julkaistu ). Lisäksi Alfresco tukee dokumenttien versiointia ja käyttäjäoikeuksien roolipohjaista hallinta. Vaikka Alfresco on web-pohjainen sovellus, ei se tarjoa varsinaista tapaa julkaista sisältöä web-sivustona. Siksi Alfrescon rinnalle on valittu portaalialusta Liferay. Liferay on Java-pohjainen Java Portlet -spesifikaation täyttävä portaalialusta. Alustan avulla voidaan julkaista sisältöä ns. portlet-sovellusten kautta. Portletit ovat pieniä näkymiä järjestelmässä olevaan tietosisältöön. Käyttäjälle portletit esiintyvät usein pieninä laatikkomaisina ikkunoina, joissa näytetään tietoa ja jonka asetuksia voi muuttaa. Hyvä esimerkki portaalista on igoogle ( Vaikka THL.fi ei varsinaisesti ole portaali, on alusta perusteltavissa portlet-sovellusten siirrettävyydellä ja uudelleenkäytettävyydellä sekä alustan tarjoamilla valmiilla komponenteilla. Alfresco ja Liferay eivät osaa suoraan kommunikoida keskenään. Alfrescossa hallittavan sisällön tuominen Liferay-portaaliin vaatii ainakin toistaiseksi jonkinlaista räätälöintiä. Erilaisia integraatio vaihtoehtoja on useita: Alfrescoa voi ajaa portlettina Liferayn sisällä, Alfresco voi jakaa tietojaan ns. Rest- tai Web service -rajapintojen kautta tai järjestelmiä voi yrittää integroida kehitteillä olevan CMIS-protokollan avulla. Alfrescon ja Liferayn käytössä on seuraavia keskeisiä vahvuuksia: Järjestelmät skaalautuvat erittäin suuriin sisältöihin Järjestelmissä on paljon ominaisuuksia valmiina Järjestelmien päälle voi melko helposti kehittää räätälöityjä sovelluksia Alfrescon ja Liferayn käytössä on seuraavia heikkouksia: Alfresco ja Liferay eivät toimi suoraan paketista yhteen Järjestelmät ovat monimutkaisia (tämä korostuu erityisesti järjestelmien yhdistelmässä) Järjestelmät vaativat alla olevalta laitteistolta paljon tehoa Kehittäjältä vaaditaan osaamista lukuisista eri sovelluskehyksistä

9 Keskeiset räätälöidyt komponentit THL.fi laajentaa Alfrescon ja Liferayn valmiita palveluita. Keskeisimmät räätälöidyt komponentit ovat: Projektiympäristön hallinta Alfrescon räätälöinti semanttisen mallin toteuttavaksi Alfrescon ja Liferayn välinen silta Ylläpitokäyttöliittymä (ns. y-käli) Näistä kaikki sisältävät merkittäviä ongelmia: Projektiympäristö on liian suuri ja sekava, Alfrescoa on räätälöity niin, että sen päivittäminen uudempaan versioon ei ole suoraviivaista, Alfrescon ja Liferayn silta on toteutettu epästandardilla ja tehottomalla tavalla, ylläpitokäyttöliittymä on keskeneräinen ja siinä on toistettu valmiita ominaisuuksia tekemättä käyttöliittymästä erityisen käytettävää. Projekti on jeattu 23 moduliin ja niitä hallitaan maven-työkalun avulla. Projektin mukana kulkee Tervesuomen, Toimintasuomen ja THL.fi:n toteutukset, Alfresco ja Liferay sekä portaalin teemat ja testitiedostot. Projekti rakentuu Proactumin kehittämän alustan (Proactum Enterprise Platform) päälle. Proactum-alusta sisältää Alfrescon ja Liferayn konfiguroinnin sekä ns. dynaamisten skriptiportlettien toteutuksen (Dynamic Script Portlet). Projektiympäristössä on useita ongelmia. 1. Koodia ja moduleja on kohtuuttoman paljon. Projektin ensimmäiseen käynnistämiseen menee noin tunti. Lisäksi projektin hahmottaminen on hankalaa, mikä vaikeuttaa jatkokehitystä. 2. Projekti pohjaa Proactum-alustaan ja on siten riippuvainen Proactumin mavenrepositoriosta. 3. Modulien välillä on vaikeasti hahmotettavia riippuvuuksia. Yhdestä modulista saatetaan viitata useaan toiseen moduliin (esim. rajapinta ja toteutus ovat eri moduleissa tai modulin konfiguraatiossa viitataan toisen modulin toteutuksiin). Lopputuloksen hahmottaminen on hankalaa. 4. Proactum-alusta on vanhenevaa teknologiaa. Esimerkiksi dynaamisia skriptiportletteja vastaava toteutus on uudessa Liferay-versiossa valmiina mukana. 5. Projekti on sotkuinen. Projektissa on paljon tyhjiä hakemistorakenteita. Vaikuttaa myös siltä, että projektissa on koodia, jota ei käytetä. 6. Samassa projektissa on sekä Tervesuomi, THL.fi että Toimintasuomi. Projekteilla on käytännössä hyvin vähän yhteistä ja siksi ne kannattaisi erottaa omiksi haaroikseen. Alfrescoa on räätälöity semanttisen mallin tarpeisiin, DocBook-ominaisuuksia varten ja LDAPlaajennoksia varten. Semanttisessa mallissa keskeisenä ongelmana on ollut hierarkkiset asiasanastot, joiden takia dokumenttiin on tarvittu varsinaisten asiasanojen lisäksi asiasanojen

10 yläkäsitteet. Yläkäsitteiden ongelma on ratkaistu lisäämällä Alfrescoon ns. Behaviour- ja Actionlaajennoksia, jotka laukeavat dokumentin lisäämisen yhteydessä. Alfresco-dokumenttiin liitetään automaattisesti asiasanojen yläkäsitteet, jolloin ne päätyvät myös haun piiriin. Lähestymistapa on monella tapaa ongelmallinen. Käyttäjän näkökulmasta dokumenttien lisääminen on hidasta, mallin näkökulmasta toteutus aiheuttaa turhaa informaation toistoa. Järkevämpi lähestymistapa olisi ollut lisätä yläkäsitteet ainoastaan indeksiin, eikä varsinaiseen tietomalliin. Toinen vaihtoehto olisi ollut käyttää terminlaajennosta haun yhteydessä. DocBook-toteutus on jäänyt kesken, joten sen tilaa on hankala arvioida. LDAP-laajennoksien tarve on myöskin epäselvä, sillä Alfrescossa pitäisi olla LDAP-tuki valmiina. Laajennoksilla on yritetty keinties kiertämää jotain autentikointiin liittyvää ongelmaa, mutta toteutuksessa on edelleen virheitä. THL.fi:n toteutuksessa on päädytty rakentamaan Javan etäproseduurikutsuihin (RMI) pohjautuva silta komponenttien välille. Ratkaisu on epästandardi ja siinä ohitetaan esimerkiksi Alfrescon tarjoamat valmiit Rest- ja Web service -rajapinnat. Lisäksi yhteys, että jokainen sivupyyntö portaalissa aiheuttaa tietokyselyitä sisällönhallintajärjestelmään. Tästä seuraa merkittäviä suorituskykyongelmia. Ylläpitokäyttöliittymässä keskeiset ongelmat liittyvät käytettävyyteen. Teknisiä pulmia aiheuttaa muun muassa keskeneräisyys sekä ylläpitokäyttöliittymän monimutkainen konfiguraatiototeutus. Lisäksi aiemmin kuvatut asiasanojen yläkäsitteiden indeksointiin liittyvät ongelmat heijastuvat ylläpitokäyttöliittymän toimintaan. Sivuston, ylläpitokäyttöliittymä mukaanlukien, oli alkuperäisissä suunnitelmissa tarkoitus olla tietomallin pohjalta rakentuva. Ylläpitokäyttöliittymään on kuitenkin rakennettu räätälöity XML-pohjainen konfigurointimoduli, joka sivuuttaa datamallin. Käyttöliittymässä näytettävät sisältötyypit listataan siis XML-konfiguraation, ei mallin, perusteella. Toimintalogiikan toistaminen sekä mallissa, että ylläpitokäyttöliittymässä tekee järjestelmän ylläpitämisestä ja jatkokehittämisestä hankalaa. Järjestelmän arvionti Järjestelmää arvioitiin sekä analysoimalla ohjelmakoodia että tarkastelemalla ohjelman suoritusta. Ohjelmakoodin analyysi perustui ns. staattiseen analyysiin sekä koodin katselmointiin. Suoritusta arvioitiin ajamalla järjestelmässä olevia yksikkö-, integraatio- ja järjestelmätestejä. Lisäksi järjestelmälle tehtiin kuormitustestaus. Ohjelmakoodin staattinen analyysi Koodin laatua voidaan arvioida niin sanotulla staattisella analyysillä. Ajatuksena arvioida ja

11 mitata koodin laatua ohjelmaa ajamatta tai kääntämättä. Mittarit perustuvat esimerkiksi hyviin ohjelmointiperiaateisiin, loogisten ehtojen testaamiseen ja koodiriippuvuuksien tutkimiseen. (Dynaamiseksi analyysiksi kutsutaan ohjelmakoodin suorittamiseen perustuvaa analyysiä, esimerkiksi yksikkötestausta. Testejä on käsitelty seuraavassa luvussa.) THL.fi-projektin staattinen analyysi suoritettiin Sonar-työkalulla 2. Projektissa on analyysin perusteella riviä koodia ( riviä mukaan lukien kommentit ja rivinvaihdot) yli neljässä sadassa tiedostossa. Luokkia on 433, paketteja 76 ja metodeja Koodimäärä sisältää pelkän räätälöidyn Java-koodin. Projektissa on lisäksi valtava määrä käyttöliittymätiedostoja (freemarker-, jsp- ja jsf-template-tiedostoja), XML-konfiguraatiota ja Javascript-koodia. Projektin lataukseen on käytetty lisäksi Bash-skriptejä. Vertailun vuoksi Palveluvaaka.fi-verkkopalvelussa on noin 4000 riviä Java-koodia. Ottaen huomioon THL.fi:n vähäisen dynaamisuuden, riviä vaikuttaa kohtuuttoman suurelta määrältä koodia. Staattisessa analyysissä koodista löytyi 77 kriittistä virhettä, 2226 merkittävää virhettä, 4286 vähäistä virhettä ja 680 huomautusta. Koodissa on toisteisuutta 2% ja pakettien välinen riippuvuusindeksi 14,6%. Poiskommentoitua koodia on 1274 riviä. Ohjelmassa ei saisi olla lainkaan kriittisiä virheitä, sillä ne voivat johtaa suorituksessa virhetilanteisiin. Merkittäviä ja vähäisiä virheitä voi tulla erilaisista koodaustyyleistä, eivätkä ne välttämättä aiheuta näkyviä ongelmia. Suuret luvut heijastelevat kuitenkin huolimatonta ohjelmointityyliä. Toisteisuusindeksi on toistuvien rivien lukumäärän suhde kaikkiin riveihin. Luku kuvaa koodin laatua siinä kuinka paljon on koodia on kopioitu metodeiksi eristämisen sijaan. Riippuvuusindeksi puolestaan kuvaa pakettien välisiä kaksisuuntaisten riippuvuuksien suhdetta kaikkiin riippuvuuksiin. Kaksisuuntaisella riippuvuudella tarkoitetaan tilannetta, jossa kaksi pakettia riippuu toisistaan. Tällöin toista pakettia ei voi muuttaa muuttamatta toista. Tilanne on ylläpidon ja jatkokehittämisen kannalta ongelmallinen. Toisteisuus- ja riippuvuusindeksien pitäisi olla nolla. Poiskommentoitua koodia ei pitäisi olla lainkaan, sillä versionhallintajärjestelmä pitää kirjaa kaikista muutoksista ja myös poistetusta koodista. Testien kattavuutta ei saatu testattua, sillä yksikkötestien ajaminen epäonnistui. Testit Projekti sisältää yksikkö-, integraatio- sekä järjestelmätestejä. Yksikkö- ja integraatiotestit on 2

12 tehty junit 3 -testeinä, järjestelmätestit Selenium 4 -testeinä. Lähtökohdiltaan projektin testaus on järkevällä pohjalla, mutta toteutus on jäänyt vajavaiseksi. Osaa yksikkötesteistä ei voitu ajaa niiden vaatiessa suoraa Internetyhteyttä. Kaikki ajetut yksikkötestit menivät läpi. Kaikissa moduleissa ei kuitenkaan ole yksikkötestejä, joten testein kattavuus ei ole täydellinen. Positiivisena puolena testejä on kohtalaisesti. Integraatiotestien avulla on testattu pääasiassa Alfresco-palvelimen toimintaa. Testien ajo on hidasta, mutta testit menevät DocBook-testejä lukuunottamatta pääasiassa läpi. Useiden peräkkäisten ajojen välillä osa testeistä epäonnistuu satunnaisesti. Testien nimeämisestä päätellen ne on tehty lähinnä Tervesuomea varten. Järjestelmätestit on toteutettu Selenium-testeinä ja niiden ajamiseen menee erittäin pitkään. Testit menevät muutamaa lukuunottamatta läpi. Testit ovat ilmeisesti käsin kirjoitettu Javakoodiksi. Koodi on sekavaa ja sitä on paljon, mikä tekee testien muuttamisesta ja niiden päämäärän ymmärtämisestä hankalaa. Yhteenvetona testeista voi sanoa, että lähestymistapa on ollut järkevä, mutta toteutus huono. Testien toimivuudesta tai järkevyydestä ei ole helppo vakuuttua nopean tutustumisen perusteella. Kuormitustestaus Toteutusvaiheessa järjestelmälle on tehty suorituskykyanalyysi, jonka perusteella toteutuksen pitäisi skaalautua noin 100 samanaikaiselle käyttäjälle. Järjestelmä vaikutti kuitenkin niin hitaalta, että suorituskykyä päätettiin uudelleenarvioida tätä raporttia varten. Testissä simuloitiin tilannetta, jossa THL.fi-etusivun haluaa nähdä samaan aikaan suuri määrä käyttäjiä (esim. kriisitilanne). Käyttäjämääräksi asetettiin aluksi 25 sitten 50, 100 ja 200. Seuraavassa on listattu keskimääräiset odotusajat etusivun näkymiseen eri käyttäjämäärillä: 6,4 s (25 käyttäjää) 13,9 s (50 käyttäjää) 29,7 s (100 käyttäjää) 82,4 s (200 käyttäjää) Toisin sanoen, 100 samanaikaisen käyttäjän tilanteessa yksi käyttäjä joutuu odottamaan noin puoli minuuttia etusivun avautumista. Todellisessa tilanteessa ennen sivun avautumista käyttäjä turhautuu odotteluun ja painaa selaimen refresh -nappia, joka laukaisee uuden sivupyynnön entisestään hidastaen palvelinta. Käytännössä näyttäisi siltä, että noin 50 samanaikaista käyttäjää on suurin määrä mitä

13 järjestelmä kykenee palvelemaan. Kriisitilanteessa piikit voivat olla tuhansissa samanaikaisissa sivupyynnöissä. Vertailun vuoksi samaa testiä kokeiltiin puhtaalla Liferay 6 -asennuksella. Järjestelmä palveli tuhatta samanaikaista käyttäjää noin neljän sekuntin keskimääräisellä viiveellä. Testaus suoritettiin Grinder-työkalulla 5. Testipalvelimena toimi pöytäkone, jossa 3 gigatavua muistia ja 4 prosessoriydintä. Tuotantopalvelin on testipalvelinta tehokkaampi. Lisäksi testipalvelinta ajettiin testikonfiguraatiolla, mikä hidastaa suoritusta esimerkiksi yksityiskohtaisen lokikirjanpidon takia. Vaikka tuotantoympäristö olisi puolet tehokkaampi kuin testiympäristö, skaalautuvuus on silti heikko. 5

14 Ratkaisuehdotuksia Tässä luvussa pohditaan mahdollisia ratkaisuja THL:n verkkosivujen toteuttamiseen. Kunkin ratkaisun kohdalta on listattu heikkouksia ja vahvuuksia. Lisäksi on pohdittu lähestymistavan vaatimaa aikaa. Järjestelmän tulee tukea ainakin seuraavia ydintoiminnallisuuksiksia: 1. Dokumenttien julkaisu (web-sisältö ja liitetiedostot) 2. Dokumenttien ja käyttöliittymän kielistys 3. Dokumentin tyyppin määritys 4. Dokumentin asiasanoitus 5. Asiasanoitukseen, dokumentin tyyppiin ja vapaatekstiin pohjautuva haku (esim. moninäkymähaku) 6. Uutisvirrat 7. Ylläpitokäyttöliittymä 8. Käyttäjäoikeuksien hallinta Ratkaisuehdotuksista kukin on jaettu omalle sivulleen. Täysin ulkoistettua vaihtoehtoa ei ole listattu, sillä ainakin tähän menessä sivujen ylläpitoa ja räätälöintiä on haluttu hallita itse. Kaksi ensimmäistä vaihtoehtoa pohjautuvat räätälöityihin toteutuksiin, jälkimmäiset valmiisiin sisällönhallintajärjestelmiin (Content Management System, CMS).

15 Vanhan järjestelmän korjaaminen Pysytään vanhassa ongelmalliseksi todetussa järjestelmässä ja yritetään korjaamalla saada sitä parempaan tilaan. järjestelmä on olemassa ei tarvita tietojen siirtoa (siinä määrin mitä muissa vaihtoehdoissa, nykyisessä järjestelmässäkään ei ole kaikkea tietosisältöä) korjaaminen on työlästä ja hidasta (tässä dokumentissa esitetyistä syistä) tarvitaan erittäin asiantuntevia kehittäjiä pitkä perehtyminen refaktorointi ja testien kirjoittaminen hallittava Alfresco ja Liferay hallittava tilanne ei parane nopeasti, laitoksen maine huononee ulkoisella välimuistiratkaisuilla (esim. Varnish) järjestelmästä voidaan saada suorituskykyisempi kohtalaisen pienellä vaivalla remontti sisältäen hakuindeksin, y-kälin, RMI:n ja LDAP:in refaktoroinnit vie kahdelta ammattitaitoiselta täysipäiväiseltä ohjelmistosuunnittelijalta 9-12kk suurempi remontti sisältäen koko koodipohjan läpikäynnin, turhan koodin karsimisen ja tarvittavat refaktoroinnit sekä kunnollisen testauksen vie kahdelta henkilöltä 1-2v. refaktorointi on hidasta ja vaativaa, työmäärä voi olla huomattavasti arviota suurempi pätevien henkilöiden löytäminen ja perehdyttäminen on hankalaa kehittäjät voivat turhautua ja lopettaa pohja (Alfresoco+Liferay) on kohtalaisen eksoottinen eikä markkinoilla ole kyseiselle alustalle paljoakaan palveluita tarjolla

16 Uusi räätälöity sivusto Aloitetaan uusi THL.fi-projekti, jossa pyritään rakentamaan uudenaikainen organisaatiosivusto räätälöitynä toteutuksena. Toteutus voi olla lähtökohdiltaan erilainen kuin nykyinen tai se voi olla nykyisen järjestelmän uudelleenkirjoitus. aikaansa edellä oleva sivusto voi palvella käyttäjiä erittäin hyvin räätälöity tarpeiden mukaiseksi vaatii paljon työtä kahdelta ammattitaitoiselta tekijältä 6kk perussisällön esittämiseen ja hallintaan, toiset 6kk kunnolliseen ylläpitokäyttöliittymään ja käyttäjäoikeuksien hallintaan, viimeistelyä 6-12kk keksitään pyörä uudestaan, olemassa olevat CMS-alustat soveltuvat (ainakin nykyisenlaisen) organisaatiosivuston toteuttamiseen varsin hyvin nykyisen toteutuksen ongelmien uusiutuminen huonoimmassa tapauksessa saadaan kallis huonosti toteutettu epästandardi sovellus, joka tekee saman mitä valmiista paketeista saadaan ilmaiseksi

17 Liferay Valitaan Java-pohjainen portaalialusta, jota nykyisessäkin toteutuksessa käytetään. Ajatuksena olisi ottaa käyttöön uusin Liferay-versio ja ilman räätälöintejä hallita sivuston perussisältö. Järjestelmä on maailmalla hyväksi todettu Paljon ominaisuuksia valmiina Java-pohjaiselle järjestelmälle löytyy osaamista Voidaan hyödyntää nykyisen sivuston ulkoasuteemoja Räätälöinti helppoa Porlet-sovellusten avulla Järjestelmä ei ole teknisesti täysin puhdas (projektilla on paljon kehittäjiä ja käytössä on useita rinnakkaisia sovelluskehyksiä) Valmiin ylläpitokäyttöliittymän käytettävyys on hieman heikko Ei tue mielivaltaista metadataa (meilivaltaisia avain-arvo-pareja) Kielistys osittain keskeneräinen Ei tue kaikkia tarvittavia ominaisuuksia (moninäkymähaku) Tarvitaan datan siirto Tarvitaan 1-2 kehittäjää Asennus ja konfigurointi 1-2kk Räätälöity haku ja sisältöpoiminnat 3-9kk Nykyisen THL.fi:n tiedonsiirto 1-3kk Testaus 1kk Perusominaisuuksien toteuttaminen räätälöitynä vie arvioitua enemmän aikaa Alustaa ei onnistuta tai voida hyödyntää täysimääräisesti

18 Liferay ja Alfresco Valitaan käyttöön nykyiset peruskomponentit, mutta toteutetaan järjestelmien välinen yhteys olemassa olevin ratkaisujen tai hyvin pienien räätälöintien avulla. Samat kuin edellisessä Voidaan hyödyntää olemassa olevia tietosisältöjä jossain määrin (malli voi silti vaatia korjausta) Valtavia aineistoja tukeva kokonaisuus Kohdataan samoja ongelmia kuin nykyisessä toteutuksessa Järjestelmien yhdistäminen vie aikaa Tarvitaan 2 ammattitaitoista kehittäjää Järjestelmien välinen yhteys 1-2kk Tietomallin päivittäminen 1-2kk lisäksi ks. Liferay-työmäärä (5-12kk) Järjestelmästä tulee liian monimutkainen hallittavaksi Pätevien kehittäjien löytäminen on vaikeaa, sillä hallittava kokonaisuus on suuri ja monimutkainen

19 Drupal Drupal on edellisistä poiketen PHP-pohjainen järjestelmä. Drupal on maailmalla paljon käytetty ja hyvänä pidetty (käytössä mm. Valkoisen talon verkkosivuilla). Järjestelmässä on runsaasti ominaisuuksia valmiina. Drupali pohjautuu avoimeen lähdekoodiin ja perusversio on ilmainen. Tarjolla on maksullisia tukipalveluita. Järjestelmä on erittäin laajassa käytössä Järjestelmää on kehitetty pitkään Kaikki tarvittavat perusominaisuudet valmiina Alkuvaiheessa ei todennäköisesti tarvita räätälöintejä PHP-pohjaiselle järjestelmälle löytyy osaamista Ylläpitokäyttöliittymä Liferayn vastaavaa viimeistellympi Kehittäminen ketterämpää kuin Javalla Käytetty kieli (PHP) jakaa mielipiteitä Alustasta ei ole talossa paljoa kokemusta Tarvitaan datan siirto Suorituskyky voi olla perusasetuksilla heikko Kehittämistyöympäristö ja sovelluskirjastot eivät ole Javan tasolla Tarvitaan 1-2 kehittäjää Alkuvaiheessa ei tarvita räätälöintejä Asennus ja konfigurointi 1-2kk Nykyisen THL.fi:n tiedonsiirto 1-3kk Testaus 1kk Ominaisuudet perustuvat pitkälti laajennoksiin, joita ei välttämättä päivitetä yhtä tiivisti kuin Drupal-ydintä Huolimattomat räätälöinnit voivat aiheuttaa mm. tietoturva-aukkoja

20 Plone Plone on Python-kieleen pohjaava sisällönhallinta järjestelmä. Python on eleganttina pidetty kieli Järjestelmään ei ole kovin laajasti tarjolla valmiita komponentteja Suorituskyky voi olla perusasetuksilla heikko Osaajia ja palveluita voi olla vaikea löytää

21 Yhteenveto Keskeisin päätökseen vaikuttava ei-tekninen kysymys koskee sivuston konseptia: halutaanko alkuperäistä tietosisältölähtöistä visiota kehittää, vai todetaanko käsin konfiguroitu osittain sisältöä automaattisesti poimiva ratkaisu riittäväksi? Alkuperäisen vision suurimpana taakkana on räätälöidyn järjestelmän tarve. Kenties riittävät haku- ja suositteluominaisuudet voidaan toteuttaa johonkin olemassa olevaan sisällönhallintajärjestelmään pieninä laajennusmoduleina (esim. portletteina), jolloin sivurakenne sekä perussisältö voidaan hallita perinteistä ylläpitotapaa tukevilla valmiilla työkaluilla.