Perusrekisteri, teknisten valintojen lähtökohdat ja periaatteet

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
• 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
• 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...

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