Mihin Pepin ja Perusrekisterin teknologiavalinnat perustuvat?
Ongelma: Korkeakoulujen järjestelmäarkkitehtuuri on syntynyt vuosien saatossa ja johtanut sekavaan tulokseen
- Järjestelmien ylläpito ja häiriötilanteiden selvittäminen on koettu ongelmalliseksi
- Arkkitehtuurin monimutkaisuus tekee hankalaksi kustannusten arvioimisen ja jatkokehittämisen, syntyy piilokustannuksia
- Tiedon kopiointi aiheuttaa sen, että tiedon omistajuus järjestelmien välillä hämärtyy ja tiedon eheys voi vääristyä
- Sekava järjestelmäarkkitehtuuri heikentää tietoturvaa
- Tiedot on kuvattu eri tavoin, joka hankaloittaa palveluiden ja toimintojen suunnittelua.
Kohti parempaa arkkitehtuuria
- Pepin esiselvitysvaiheessa käytiin läpi eri ratkaisumalleja ja selvitettiin miten nykyiset ongelmat voidaan ratkaista
- Palvelupohjainen arkkitehtuuri koettiin sopivammaksi
- Palvelualustatuote valittiin PoC-projektien tulosten perusteella
Evaluoinnit tehtiin seuraavia skenaarioita vasten: https://wiki.kuali.org/display/KULRICE/SOA+Questions+-+Eduix
Toimittajan näkökulma perusrekisteri-projektin teknologiavalintoihin
- Järjestelmäkehityksen on oltava hallittua ja kustannustehokasta
- Teknologiavalinnat sellaisia, että kehittäjiä on löydettävistä ja kehitystyövälineet ovat helposti saatavilla
- Vältetään riski "kehittää itsensä hengiltä"
- Järjestelmän jatkumo vähintään 20 vuotta
- Mahdollistetaan järjestelmän jatkokehitys monella tasolla; oltava helposti jatkokehitettävissä ja ennenkaikkea ylläpidettävissä (järjestelmän kokonaiskustannuksista iso osa menee ylläpidoon)
- Ei tehdä yksinkertaisista asioista rakettitiedettä
Teknologiavalinnoista
- Palvelut ja integraatiot
- Koodi ei ole sidottu tiettyyn alustaan
- Moduulit ovat Java-koodia, jotka voidaan paketoida ajettavaksi mihin tahansa Java-alustaan
- Palvelualustan evaluoinnin tuloksena päädyttiin ServiceMix4-integraatioalustaan, jonka perustana on OSGi-teknologia ja OSGi-valmiit sovelluskehykset (Camel, CXF, ActiveMQ...)
- OSGi: modulaarisuus, versiointi, palvelurekisteri...
- Käyttöliittymäkerros
- Valittu ajoalustaksi Liferay-portaali, joka tällä hetkellä olevista portaaleista käytetyin, käytetään arkkitehtuurissamme mm:
- näkymäkerroksen autentikointi ja auktorisointi
- näkymien organisointi (työpöytien koostaminen käyttäjän identiteetin perusteella)
- staattisen, lokalisoidun sisällön tuottaminen, mm. ohjeet, tiedottaminen CMS.työkalun avulla
- Palveluiden käyttöliittymät (portlet)
- koodin uudelleenkäytettävyys keskeistä, templatet tehty html:lle ja javascripteille
- Freemarker helppokäyttöisenä template-moottorina
- Valittu ajoalustaksi Liferay-portaali, joka tällä hetkellä olevista portaaleista käytetyin, käytetään arkkitehtuurissamme mm:
- Keskeistä on, että arkkitehtuurille asetetut vaatimukset ratkaistaan kustannustehokkaasti (referenssinä Peppi-projekti)
Kehityssuunnat
Palvelualustan tulevaisuus:
- ServiceMix5 sisältää enää oletuksellisesti kokoelman Apachen integraatiotuotteita (esim. JBI poissa)
- eli sisältää juuri ne teknologiavalinnat, jotka Pepissä / Perusrekisterissä on tehty
- ei kuitenkaan tarkkaa tietoa mihin suuntaan kehitys on menossa
- Keskeistä on, että palvelut ovat edelleen ajettavissa missä tahansa Java-ympäristössä
- Taustaa
- Fusesource myytiin Redhatille, tuloksena kaksi versiota:
- fabric8 (opensource / community projekti) ja JBoss Fuse (kaupallinen, tuettu versio)
- Paljon liikehdintää Redhat / JBoss Fuse sektorilla, fabric8 kehittyy nopeasti
- Fusesource myytiin Redhatille, tuloksena kaksi versiota:
- fabric8 lyhyesti:
- fabric8 mahdollistaa profiilien (joukko artifakteja, asetustiedostoja... ) ajamisen containereissa (Java Container, Docker...), joita hallitaan keskitetysti
- container-ajattelu trendi maailmalla, keskeistä pilvipalveluissa
- esim. perusrekisterin tapauksessa: opiskelijan palvelut omassa profiilissa, jota ajetaan omassa containerissa
- palveluiden versiointi helpompaa
- tallentaa konfiguraatiomuutokset sisäiseen git repositoryyn mahdollistaen esimerkiksi muutosten peruuttamisen (rollback)
- continuous deployment
- hallintakäyttöliittymät kehittyneet (ja toimivat myös ServiceMix5-jakelussa)
- monitorointi, konfigurointi, visualisointi...
- fabric8 mahdollistaa profiilien (joukko artifakteja, asetustiedostoja... ) ajamisen containereissa (Java Container, Docker...), joita hallitaan keskitetysti
Näkymäkerroksen tulevaisuus
- Eduixilla vuosien kokemus portaalituotteista (Sun Portal Server, Novell Extend, Glassfish Webspace Portal, JBoss Portal, Liferay)
- Portaaliratkaisuissa kymmeniä tuhansia käyttäjiä ja satoja tuhansia transaktioita päivä
- Vahva näkemys millainen portaalituotteen / näkymäkerroksen tulee olla, jotta sitä on helppo jatkokehittää ja ymmärtää
- Ei keksitä pyörää uudestaan - eikä kehitetä itseämme hengiltä, paitsi että...
- Eduix on aloittanut sisäisen selvititystyön käyttöliittymäkerroksen uudistamiseksi ("Scales")
- päämääränä skaalautuva, kevyt ja ylläpidettävä käyttöliittymätuote
- tavoitteena avoimen lähdekoodin projekti, jonka kehitykseen kaikki voivat osallistua