LADOK
Utvecklingsmöjligheter ny systemgeneration
– tekniska möjligheter och risker
Marcus Gelderman
den 10 juni 2008
GEM T-8004
Innehållsförteckning
SAMMANFATTNING.................................................................................................................................................. 4 Utredningens uppdrag.................................................................................................................................................................4 Bakgrund ...........................................................................................................................................................................................4 Uppdraget enligt utredningsdirektiven ...............................................................................................................................4 Utredningens genomförande ....................................................................................................................................................5 Kortfattad summering av utredningens resultat.............................................................................................................5 Argument för en ny version av Ladok ...................................................................................................................................7 SYSTEM OCH VERKSAMHETSKRAV..................................................................................................................... 8 Indelning av krav ...........................................................................................................................................................................8 FUNKTIONELLA SYSTEM OCH VERKSAMHETSKRAV .................................................................................................................... 8 Rapportering och registrering .................................................................................................................................................8 Skyddade identiteter, anonyma tentor, egna kursval....................................................................................................8 Källa till data för kringliggande system ..............................................................................................................................9 Underlag för ut­ och inbetalningar och statistik .............................................................................................................9 Grundläggande katalogfunktion.............................................................................................................................................9 FRAMTIDA FUNKTIONELLA SYSTEM OCH VERKSAMHETSKRAV ............................................................................................. 10 Självadministration ................................................................................................................................................................... 10 Högskolorna önskar en bättre processanpassning av stödet.................................................................................. 10 Ökat utbyte av data och mera avancerade systemintegration scenarios.......................................................... 11 Effektivare drift och kontrollerade utvecklingskostnader........................................................................................ 11 Ökad systemintegration........................................................................................................................................................... 12 TEKNIK OCH SYSTEMARKITEKTUR ..................................................................................................................13 FUNKTIONELLA KRAV FÖR ATT LÖSA VERKSAMHETENS BEHOV ........................................................................................... 13 MÖJLIGA TEKNISKA VÄGVAL MED NUVARANDE LÖSNING....................................................................................................... 13 RISKER MED NUVARANDE LÖSNING ........................................................................................................................................... 13 VÄGANDE SKÄL FÖR EN TEKNISK OMBYGGNAD AV SYSTEMET .............................................................................................. 14 Drift och underhåll ..................................................................................................................................................................... 14 Kostnader för licenser............................................................................................................................................................... 15 Kompetensbehov ......................................................................................................................................................................... 15 Uppfyllande av förändrade omvärldskrav....................................................................................................................... 15 TEKNISKA VÄGVAL FÖR EN FRAMTIDA LÖSNING ...................................................................................................................... 16 Visionära möjligheter och enkel teknik för framtiden ............................................................................................... 16 Ny datamodell och migration................................................................................................................................................ 19 Krav på drift och underhåll .................................................................................................................................................... 21 Framtida kompetensbehov..................................................................................................................................................... 21 SÄKERHET OCH TILLGÄNGLIGHET ...................................................................................................................22 TILLGÄNGLIGHET ........................................................................................................................................................................... 22 Version 1.1 – Marcus Gelderman, email: [email protected]
1 / 45
Den nuvarande lösningen........................................................................................................................................................ 22 Framtida krav på tillgänglighet........................................................................................................................................... 22 Identifierade risker .................................................................................................................................................................... 22 DATASÄKERHET ............................................................................................................................................................................. 23 Den nuvarande lösningen........................................................................................................................................................ 23 Framtida säkerhetskrav........................................................................................................................................................... 23 Identifierade risker .................................................................................................................................................................... 23 ÅTKOMSTKONTROLL ..................................................................................................................................................................... 23 Framtida krav för åtkomstkontroll .................................................................................................................................... 23 Identifierade risker .................................................................................................................................................................... 24 FRAMTIDA MÖJLIGHETER ............................................................................................................................................................. 25 Singel Sign On (SSO) och autentisering utanför systemet ........................................................................................ 25 Elektronisk id och autentisering av studenter ............................................................................................................... 25 Rollbaserad säkerhet................................................................................................................................................................. 26 Kryptering, Certifikat och digitala signaturer ............................................................................................................... 26 NATIONELLA OCH INTERNATIONELLA TEKNISKA SAMARBETEN .........................................................27 FRAMTIDA MÖJLIGHETER ............................................................................................................................................................. 27 Krav på en framtida lösning .................................................................................................................................................. 27 Möjligheter i den nuvarande lösningen ............................................................................................................................ 28 Datastandarder ........................................................................................................................................................................... 28 Internationella samarbeten ................................................................................................................................................... 29 BESLUTSKRITERIER FÖR OMBYGGNAD OCH KOSTNADSASPEKTER.....................................................30 BESLUTSKRITERIERNA FÖR ETT BESLUT OM OMBYGGNAD .................................................................................................... 30 KOSTNADSASPEKTER .................................................................................................................................................................... 30 TEKNISKA BILAGOR ...............................................................................................................................................31 HIBERNATE ..................................................................................................................................................................................... 31 Summering..................................................................................................................................................................................... 31 Hibernate i princip ..................................................................................................................................................................... 31 Prestanda och Hibernate......................................................................................................................................................... 32 Att förstå Hibernate................................................................................................................................................................... 33 Hibernate­kunskap..................................................................................................................................................................... 33 Snabbsummering för­ och nackdelar................................................................................................................................. 33 Summering..................................................................................................................................................................................... 34 Standarder och tekniker som stöds av JBoss AS ............................................................................................................ 34 WEB SERVICE, SOAP OCH WSDL.............................................................................................................................................. 36 Web Service ................................................................................................................................................................................... 36 SOAP.................................................................................................................................................................................................. 36 Web Services Description Language (WSDL)................................................................................................................. 36 XML ................................................................................................................................................................................................. 37 XML SCHEMA ................................................................................................................................................................................. 38 Version 1.1 – Marcus Gelderman, email: [email protected]
2 / 45
JAVA ARCHITECTURE FOR XML BINDING (JAXB) .................................................................................................................. 39 SPRING FRAMEWORK .................................................................................................................................................................... 40 Inversion of Control container .............................................................................................................................................. 40 Aspect­orienterad programmering..................................................................................................................................... 40 ESB (ENTERPRICE SERVICE BUS)............................................................................................................................................... 41 JAVA MESSAGE SERVICE (JMS)................................................................................................................................................... 42 JUNIT................................................................................................................................................................................................ 43 ASYNCHRONOUS JAVASCRIPT AND XML (AJAX)..................................................................................................................... 44 Version 1.1 – Marcus Gelderman, email: [email protected]
3 / 45
Sammanfattning
Utredningens uppdrag
I detta avsnitt ges först en bakgrund till utredningsuppdraget. Därefter beskrivs innehållet i utredningsdirektiven,
samt utredningens genomförande och slutligen en summering av det resultat som utredningen har kommit fram
till samt en sammanfattning av argument för att uppgradera Ladok-systemet till en nyare systemrevision.
Bakgrund
Ladok-systemet har just gjort sig av med den äldsta teknikgenerationen och det finns inte några omedelbara hot
eller krav på att snabbt bygga en ”nästa systemgeneration”. Dock är man medveten om att omvärlden förändras och detta kan i sin tur motivera en förändring av det systemstöd som behövs för att effektivt stödja verksamheten. Denna utredning fokuserar i huvudsak på tekniken och vad som är aktuell teknik idag och i möjligaste mån vad man kan förvänta sig av framtiden. Utredningen utgår ifrån i att man i grova drag hanterar samma
typ av information som det befintliga Ladok-systemet gör i dagsläget, men ser samtidigt att vissa omvärldsfaktorer redan har förändrats som kan föranleda systemförändringar:
•
Studenterna förväntningar på Ladok är förändrade, de kommer i större grad fungera som medaktörer
och ha ett större intresse för informationen i Ladok
•
Utbyten av studenter och information om studenter ökar drastiskt nationellt och internationellt.
•
Studenternas förväntningar på systemassistans har kraftigt skruvats upp och förändrats,
•
Högskolornas ekonomiska situation nödvändiggör effektivare systemstöd.
•
En nära släkting, NyA har kommit med som ny aktör och fokuserat på behovet av effektiv samverkan
mellan system.
•
Medvetenhet om vilka krav som kan ställas på systemstödet har mognat.
Uppdraget enligt utredningsdirektiven
I utredningsdirektiven stipuleras att utredningen skall redovisa de allvarligaste beslutskriterierna som kan nödvändiggöra en ombyggnad av systemet, visa på vilka tekniska lösningar som finns om man väljer att bygga om
systemet, samt tydliggöra möjligheterna med dessa tekniska vägval. Utredningsdirektivet anger också att risker
med den nuvarande tekniska skall tydliggöras, samt redovisa vilka systemförändringar som behöver göras för
att möta de förändrade omvärldskraven. Säkerhet i den befintliga lösningen skall redovisas, samt hur krav på
säkerhet kan förändras i framtiden. Hänsyn skall också tas till internationella och nationella tekniska samarbeten
i nuvarande lösning och en eventuell framtida lösning. Den visionära aspekten är viktig och utredningen skall
redovisa olika alternativ för systemarkitektur och preliminärt värdera de tekniska utvecklingsmöjligheterna och
riskerna med utgångspunkt i dagens system och utifrån en eventuell framtida förändring av systemet.
Utredningen skall även ge grund för beslut om fortsatt planeringsarbete för nästa systemgeneration och ge
Konsortiet en beredskap för att snabbare kunna påbörja arbetet med teknikskifte när så krävs.
I egenskap av extern och oberoende part så skall utredningen enligt direktivet, förutom ovanstående punkter,
också redovisa sin syn på möjligheterna att minska riskerna för framtida leverantörsberoenden.
Version 1.1 – Marcus Gelderman, email: [email protected]
4 / 45
Utredningens genomförande
Bakgrunden till utredningen är framtagen via intervjuer av systemanvändare, systemförvaltare och representanter för konsortiet; genomgång av systemdokumentation på Ladok-webben samt dokumentation som gjorts tillgänglig för mig i samband med intervjuerna.
Kortfattad summering av utredningens resultat
Den bästa framtiden för Ladok ur ett drifts- och utvecklingsperspektiv är enligt utredarens uppfattning att systemet skall vara Java-baserat. En direkt fördel av detta är att man kommer att effektivt kunna nytta av den Linux-arkitektur som man valt att satsa på. Java-arkitekturen innebär också att det blir enklare och mer kostnadseffektivt att handla upp externa konsulttjänster i den mån man önskar i jämfört med den nuvarande Uniface miljön.
Utöver Java som programmeringsspråk så bör man webbifiera hela lösningen och låta alla, både de som arbetar dagligen och studenter ansluta till Ladok via ett webb interface. Konsortiet bör också i möjligaste mån vara
ansvarig för utvecklingen och leverera en lösning som har all eller väldigt mycket av den funktionalitet som systemet förväntas ha. Valet att välja bort Mimer som databas till fördel för MySQL anser utredaren vara strategiskt viktigt då MySQL som produkt har betydligt bättre framtidsutsikter och troligtvis betydligt bättre prestanda.
Utöver bytet av databas anser utredaren att man bör nyttja ett objekt-till-relations databasverktyg för att tydligare kapsla in objekten och samtidigt korta ned utvecklingstiden. I dagsläget är det givna valet Hibernate som är
en open source lösning för objekt-till-relations mappningar. För att få dessa tekniker att hänga ihop, samt att få
en miljö att köra dem i, rekommenderas att man väljer applikationssevern JBoss. JBoss är också open source
och anses som en av de bättre produkterna på marknaden oavsett hur licensen ser ut. En lösning baserad på
Linux, MySQL, Hibernate och JBoss är till stor del en defacto standard uppsättning och det är relativt enkelt att
köpa till support (exempelvis från Redpill http://www.redpill.se eller något annat företag) och allt ifrån små enmans konsultbolag till de stora jättarna på marknaden har personal som kan jobba med dessa tekniker ifall man
vill ha möjlighet att köpa in konsulttimmar externt. Denna mjukvarusammansättning bör ge stora besparingar på
licens- och supportkostnader vilket rimligtvis är en viktig faktor i sammanhanget.
Lösningsarkitekturen bör vara byggd på ett sådant sätt att inga applikationer utanför Ladok applikationerna har
direkt tillgång till databasen. All kommunikation med systemet bör ske på tre olika sätt, användare interaktion via
ett webbinterface, via en Web Service-koppling för de applikationer som finns lokalt i anslutning till systemet
alternativt via en ESB (Enterprice service bus) lösning som på Ladok-sidan är JMS baserad och kopplad mot en
integrationslösning. Valet av vilken integration-/middleware-lösning som man väljer är upp till respektive läroanstalt men med kravet att det kan prata JMS mot Ladok.
Meddelanden som utväxlas mellan de olika Ladok-systemen och kring liggande system och passerar över en
ESB (Enterprice service bus) lösning. ESB skall processa meddelanden som är krypterade och baserade på
XML. XML-meddelandena skall valideras mot ett XML Schema som definierar hur data skall se ut syntaxmässigt. Snabba mekanismer som Java Architecture for XML Binding (se JAXB) används för att läsa upp meddelande i minnet för processning.
Version 1.1 – Marcus Gelderman, email: [email protected]
5 / 45
Arkitekturen bör också vara byggd på ett sådant sätt att ett fysiskt system kan hantera flera läroanstalter, samt
att flera fysiska installationer skall gemensamt kunna adressera behovet för en läroanstalt. Fördelarna med ett
sådant system är att man har en flexibilitet att flytta funktionalitet tillfälligt mellan fysiska system vid exempelvis
uppgradering eller support på hårdvara, samt att man ges möjligheten att med ganska enkla medel kan höja
prestandan genom att installera ytterligare maskinvara parallellt med befintliga system.
För att adressera behovet av att kunna få ut rapporter ur systemet bör ett enklare rapportverktyg konstrueras
som kan anpassas efter de krav läroanstalterna har. Rapportverktyget bör dels gå att använda interaktivt via
webb interfacet samtidigt som man skall kunna svara på fördefinierade frågor som når Ladok via Web Service
frågor eller via integrationslösningen (ESB).
Utöver de tidigare nämnda teknikerna så bör man dra nytta av ramverk som Spring Framework
(http://www.springframework.org/) för att förenkla utvecklandet. Under utvecklingen bör nyttja enhetstester och
ramverket JUnit (http://www.junit.org/), samt utvecklingsplattformen Eclipse (http://www.eclipse.org/) och man
bör väldigt tidigt i projektet sätta upp källkods revisions hantering (exempelvis Subversion från
http://subversion.tigris.org/).
Webbklient-delen av systemet bör vara baserat på JavaScript och XML (Ajax) och lämpliga ramverk kan vara
JBoss Richfaces (http://www.jboss.org/jbossrichfaces/) SproutCore (http://www.sproutcore.com) eller exempelvis MyFaces (http://myfaces.apache.org/). Vad man väljer här är avhängt hur man vill att kontroller och knappar skall se ut, samt om man har speciella funktionella krav. Beslutet om vilket ramverk som skall användas på
klientsidan behöver vara väl förankrat hos de som kommer utveckla systemet. Tvingar man på utvecklarna ett
klient ramverk som de inte är nöjda med kommer det påverka resultatet negativt och deras upplevelse av klient
ramverket kommer i viss mån sätta tonen för om projektet är lyckat eller inte. Viktigt att förstå är att det finns en
större mängd klient ramverk att välja mellan och vissa av dessa är otroligt effektiva om man använder dem på
precis det sättet som de var tänkta för, om sättet att utveckla eller kravbilden avviker ifrån det optimala användningssättet kan klient ramverket istället bli ett stort problem.
Utöver själva kodandet bör man ha en iterativ utvecklingsmodell och nyttja någon av de erkända agile metoder
och ramverk som exempelvis Scrum, DSDM/Atern, lean programming.
För att summera ovan text och placera in det i det befintliga systemets miljö är det utredarens uppfattning
att man bör bygga ut den funktionalitet som LpW (Ladok på webb) erbjuder fast på en ny plattform; ersätta
Nouveau- och Uniface-lösningen med en webblösning. Konsortiet bör lägga energi på att ta fram det webbinterface som behövs för att kunna nyttja funktionalitet. Man bör bygga vidare på konceptet med Web Service
(SOAP) tjänster fast på en uppdaterad plattform. Ersätta LadokPing med en integration/ESB lösning och skicka
krypterade XML baserade meddelanden. Ersätta en del av funktionaliteten av STAM genom att nyttja http/s för
användare inloggning på webben och Web Service (SOAP) anrop.
Version 1.1 – Marcus Gelderman, email: [email protected]
6 / 45
Argument för en ny version av Ladok
•
Svårigheter att på sikt underhålla den befintliga databaslösningen.
•
Svårt att överblicka säkerheten i det befintliga systemet.
•
Lappverket av applikationer gör framtida utveckling svår.
•
Uniface-lösningen är inget att bygga en framtida lösning på.
•
Framtida integrationskrav kommer att kräva en mer integrerad systemlösning.
•
Svårt att möta framtida krav på mer interaktiva webbsidor i nuvarande lösning (Ajax)
•
Databasen behöver moderniseras, risk finns att tabellerna växer okontrollerat.
•
Ett mer objektorienterad system blir billigare att underhålla och utveckla i.
•
Nyare tekniker kommer ge en bättre plattform för framtiden.
•
Drift- och underhållskostnaderna blir lägre i en enhetlig miljö för alla lärosäten.
Version 1.1 – Marcus Gelderman, email: [email protected]
7 / 45
System och verksamhetskrav
Indelning av krav
Den delen av verksamheten som berörs av Ladok-systemet är enligt min uppfattning så starkt kopplad till systemet att jag valt att inte i detalj separera system och verksamhetskraven. Detta för att hålla ihop faktorer som
tillsammans ger ett krav från verksamheten; exempelvis leder troligtvis kravet att minska administratörernas administration av de uppgifter som användarna själva kan administrera (ett verksamhetskrav) till att man behöver
öka tillgängligheten till systemet till i princip dygnet runt, 24-7 (ett systemkrav) denna separation kommer att behöva göras tydlig i samband med att med att en kravspecifikation tas fram för en eventuell ombyggnad av systemet.
Funktionella system och verksamhetskrav
Rapportering och registrering
Huvudgruppen av användare jobbar med rapportering och registrering, exempelvis kursrapportering och examenshantering. Beroende på hur läroanstalten är organiserad kan arbetet som gör i Ladok vara uppdelad på en
större mängd personer i personalen eller utförs arbetet i Ladok ett fåtal personer som då utför fler typer av sysslor i systemet. Variationen i sättet att kombinera rollerna på respektive läroanstalt ställer krav på flexibilitet för att
uppnå mesta möjliga effektivitet. Skillnaderna i hur man nyttjar systemet ställer också andra krav på flexibilitet
och möjligheter till lokala förändringar i systemkonfigurationen.
Skyddade identiteter, anonyma tentor, egna kursval
Systemet ställs också inför kravet att man skall kunna hantera personer med skyddade identiteter. Rättning av
tentan skall ske utan att personen som rättar skall ha möjlighet att sen personnummer eller namn och på så sätt
undanröja misstanke om orättvis bedömning eller jäv. Systemet måste också stödja det faktum att en större
andel av studenterna inte går igenom utbildnings- och examensprocessen linjemässigt utan i allt större utsträckning komponerar ihop en egen utbildning av fristående kurser. Detta i sin tur ställer i sin tur krav på Ladoks möjligheter till manuell hantering för dispenser, samt möjligheter att i efterhand komplettera kursinformation
som kan ha saknats vid tidpunkten för dispensgivande.
Version 1.1 – Marcus Gelderman, email: [email protected]
8 / 45
Källa till data för kringliggande system
Ladok-systemet är den ursprungliga källan för data som sedan används i kringliggande system och som källa
måste data i systemet vara aktuellt och korrekt. För att korrektheten skall kvarstå i takt med att roller förändras
behövs det även mekanismer för att bevara historik; exempelvis skulle man kunna tänka sig att en student börjar
läsa på en läroanstalt för att senare i livet går över för att undervisa på samma läroanstalt. I en sådan situation
måste man ju kunna hantera kronologin i händelserna. Även i fall där exempelvis en lärare byter befattning så är
det viktigt att kronologin behålls, detta för att undvika att historisk och aktuell data blandas på ett felaktigt sätt;
ett senare utdrag ut Ladok-systemet skulle kunna ge sken om att examinatorn för en kurs var professorn eftersom personen innehar professuren nu, dock inte när den aktuella examineringen skedde.
Underlag för ut- och inbetalningar och statistik
Ladok-systemet ger också underlag för läroanstaltens ersättning ifrån staten för utbildningsplatsen, samt studentens ersättning ifrån CSN vilket ställer tydliga krav på kvalitet och hantering av data. Utöver den data och
statistik som staten och CSN behöver för in- och utbetalningar, behöver läroanstalten möjligheten att sammanställa statistik. Det kan vara uppgifter som behövs för att styra den egna verksamheten, men det kan även vara
ett krav för att följa offentlighetsprincip t ex vid frågor ifrån press.
Grundläggande katalogfunktion
Ladok-systemet skall även fungerar som en grundläggande katalogfunktion kring en mängd uppgifter så som:
•
Studerande och deras utbildningsnivå (grund-, avancerad och forskarnivå)
•
Lärare
•
Kurser
•
Kursomgångar och anmälningsmetoder
•
Program
•
Läsårsplaner (kursomgångar i programmet under läsåret)
•
Organisation och relationer (Vem som tillhör vilken institution)
•
Externa partners
•
Antagningsuppgifter
•
Registreringar
•
Resultat
•
Tillgodoräknanden
•
Examina
•
Rapporter
•
Listor
•
Intyg
•
Examensbevis och kursintyg
•
Uppföljning
Version 1.1 – Marcus Gelderman, email: [email protected]
9 / 45
Framtida funktionella system och verksamhetskrav
Självadministration
Om man ser på hur förändring har skett inom andra områden som t ex bankväsendet så har en kostnadsmedvetenhet ifrån de aktuella organisationerna tvinga fram en mer utpräglad självadministration, vi registrerar själva
våra räkningar i internetbanken idag; en syssla som tidigare bankkassörskan utförde åt oss. Denna självadministration har också i viss mån förändrat vår egna syn på data i systemen och våra krav på insyn i de olika systemen. En högst trolig utveckling även för Ladok-systemet är att studenterna fungerar som tydliga medaktörer,
graden av självadministration ökar och kraven på insyn i systemet är kraftigt förändrade. Kravet på genom vilka
kanaler kommuniceringen skall ske kan komma att förändras, i dagsläget kan man ju se teknik som webb och
e-post som självklara. I den ganska nära framtiden kanske kraven ställ på annan mer mobil teknik som SMS
eller att webben är anpassad för mobila plattformar som t ex Apples iPhone. Det troliga är också att man expanderar kommunikationskanalerna, e-post kommer inte ersättas med SMS, utan användaren vill kunna välja
kommunikationssätt beroende på vad som skall kommuniceras; exempelvis kanske man vill ha kursplanen tillgänglig på webben och samtidigt kunna få den utskickad via e-post vid eventuella förändringar. Studenten kan
ha en önskan om att se den grundläggande tentamens planeringen via webben, hemma vid sin dator, men
samtidigt vilja få en påminnelse via SMS om plats och tidpunkt till sin mobiltelefon en kort period innan den aktuella tentamen skall ske. Möjligt är också att studenten genom att svara på SMS meddelandet även kan meddela om han eller hon tänker närvara. Troligt är också att man kommer vilja ha tillgång till systemet i princip dygnet runt, året runt (24-7) och kravet på realtids-access till data ökar markant.
Rätt utvecklad och nyttjad ger den ökade självadministrationen både ekonomiska fördelar; man kan frigöra resurser ifrån en del av student- och kanske även läraradministrationen och nyttja de mer effektivt inom andra områden och man når även administrativa fördelar; uppgifter som t ex kontaktuppgifter eller liknande är lättare att
hålla aktuella och uppdaterade av de som direkt berörs av uppgifterna. För att detta skall kunna uppnås måste
det finnas tydliga incitament till självadministration. Funktionaliteten måste vara lättanvänd och kunna användas
utan att allt för omfattande krav på utbildning i hur systemet fungerar. Balanserar man inte incitamentet med
användarvänlighet så kan motsatt effekt uppstå; exempelvis om kravet för att få ut sina studiemedel är att man
fyller i uppgifter i systemet (ett tydligt incitament) och det är svårt att förstå hur man skall kunna mata in de uppgifter som krävs (dålig användarevänlighet) kommer support och administration att bli kontaktade av ett flertal
användare som behöver hjälp och därefter från användare som vill verifiera att det som matats in är korrekt. Enkelt förklarat måste Ladok-systemet vara tydligt och enkelt att använda, det måste i möjligaste mån följa den
gällande uppfattningen av vad som är standard.
Högskolorna önskar en bättre processanpassning av stödet
Administratörernas sätt att arbeta i Ladok-systemet kommer troligtvis också behöva ses över, i takt med att
studenterna och lärarnas användande av Ladok kommer förändras kommer detta troligtvis också förändra administratörernas sätt att arbeta. Vissa administratörsuppgifter kan komma att försvinna eller minska i omfattning i
och med att fler användare administrerar i viss mån sina uppgifter själva, vissa administratörsuppgifter kommer
att tillkomma i och med det förändrade användandet, men framför allt kommer kravet på uppdaterad och korrekt information öka med en kraftigt ökad insyn. För att detta krav skall kunna tillgodoses bör man se över hur
administratörernas arbete utförs och försöka anpassa systemet efter hur deras arbetssituation ser ut. Ett ökat
workflow tänk kan vara en lösning, där man identifierar och underlättar de vanligaste arbetsuppgifterna i Ladok
Version 1.1 – Marcus Gelderman, email: [email protected]
10 / 45
och ser till att dessa är snabba och okomplicerade att genomföra. Användaren bör få information om vad som
är förväntat att utföra samt få påminnelser gällande saker som inte är utförda. Genom att ha tydliga formulär och
tydligt indikera vad man vill ha svar på kan man effektivisera kontakterna mellan exempelvis studenter och personalen som sköter administrationen.
Ökat utbyte av data och mera avancerade systemintegration scenarios
Dagens studenter är mer rörliga än innan och behovet av utbyte av information rörande studenter ökar drastiskt
nationellt och internationellt. I dagens systemvärld är det sällan ett system det enda och vanligtvis arbetar företag och institutioner med en större mängd datorsystem som stödjer olika delar av verksamheten. Skälen till detta kan vara många, allt ifrån rent historiska till en tydlig inriktning mot ett ”best of breed”-tänk där man nyttjar
varje system till det de anses vara bäst på. Oavsett anledning till en varierad systemflora så skapar detta ett krav
på goda möjligheter till att överföra information i mellan de olika systemen, att integrera systemen. När det gäller
systemintegration så brukar man separera den i två delar, intern systemintegrationen, samt extern systemintegration. Traditionellt så brukar man ställa andra krav på teknikens tillförlitlighet och standarder när det gäller systemintegration mot en extern part; exempelvis kan kommunikation gå över nätverk som man inte kontrollerar
inom verksamheten och man ställer andra krav på kvittenser och liknande. I Fallet med Ladok så skulle jag vilja
dela upp det integrationsbehovet som läroanstalten har lokalt som intern systemintegration och i de fallen man
kommunicerar med omgivande parter som CSN, andra läroanstalter, både nationellt och internationellt, som
extern systemintegration. I och med den ökade kommunikationen med kringliggande system blir kravet på dataintegriteten betydligt mycket högre och mycket mer utförliga kontroller av data behövs innan det tas in i systemet. Kravet blir att tydligt definierade interface för systemintegration måste finnas tillgängliga. En vinst av att ha
en tydlig policy och tydligt definierade interface vid all systemintegration (både intern och extern) är att mycket av
tekniken kan återanvändas och att det är tydligt specificerat hur det skall göras. Två viktiga faktorer vid val av
lösning och teknik är dels att underhållet måste hållas minimalt; i takt med att antalet kopplingar ökar blir underhållskravet väldigt betungande i annat fall. Den andra faktorn är att lösningen måste gå att övervaka effektivt, det
är samma sak här som med underhållet, ett fåtal kopplingar går att övervaka ganska enkelt oavsett lösning men
blir dessa fler så blir det genast svårare utan bra verktyg.
Effektivare drift och kontrollerade utvecklingskostnader
Läroanstalternas ekonomiska situation nödvändiggör effektivare systemstöd, dels behöver man sänka utvecklingskostnaderna för att kunna effektivt driva systemutvecklingen vidare, dels kommer man vilja minska driftskostnaden . Ett problem med den nuvarande lösningen är att en del av utvecklingen lämnats åt respektive läroanstalt. Det finns en API att nyttja (Web Service API) men själva webb utformningen har lämnats åt respektive
läroanstalt. Bakgrunden till detta var att man ursprungligen ansåg att utformningen av webben kunde vara ett
sätt för respektive läroanstalt att profilera sig mot studenterna. Tanken var säkert god men resultatet blev att
systemet ur ett webb perspektiv inte nyttjas fullt ut. Underhålls- och driftskostnaderna påverkas ju också av att
läroanstalten är ganska unik med sin lösning och inga direkta möjligheter till enhetlig drift och dela kostanden på
flera ges med en sådan lösning. Önskemål från verksamheten är att kunna sänka kostanden för lokal utveckling;
göra informationen i Ladok enklare att nå för lokala system på läroanstalten med bibehållen säkerhet för data.
En önskan finns om att kunna minimera underhållbehovet av kopplingar mot lokala system rent generellt, men
särskilt vid släpp av nya system versioner.
Version 1.1 – Marcus Gelderman, email: [email protected]
11 / 45
På konsortienivå finns det önskemål av att sänka utvecklingskostnaderna. Minska antalet fel i leveranserna,
samt minimera kostnaderna vid utrullning av nya versioner, då utan att försvåra för snabba rättningar av fel.
Ökad systemintegration
I takt med att Ladok-systemet nyttjas mer kommer behovet att föra över kataloguppgifter och meriter på elektronisk väg öka. Redan har man noterat att systemet NyA har påverkat behovet av effektiv samverkan mellan
system. Om man väljer att modernisera systemet är ökad tillgänglighet via integration en av de punkterna som
man bör lägga mycket energi på. I dag är det mer regel än undantag att man nyttjar information från flera system i de olika verksamhetssystemen. Det man med säkerhet kan säga är att det är väldigt svårt att veta när
man bygger systemen vilken information som man vill kunna nyttja i omkringliggande system. Dessa faktorer
visar tydligt på kravet av bra integrationsmöjligheter. Tittar man specifikt på Ladok-systemet så finns ju redan
kravet på integration med kringliggande system. I dagsläget löser man det via SQL frågor mot databasen, vilket
inte är helt lämpligt om man har höga krav på säkerhet och vill ha kontroll på hur prestandan nyttjas. Lämpligt är
en ESB (Enterprise service bus) lösning och tydligt definierade XML meddelande, där man kan hantera kryptering och validering.
Version 1.1 – Marcus Gelderman, email: [email protected]
12 / 45
Teknik och systemarkitektur
Funktionella krav för att lösa verksamhetens behov
Verksamheten använder idag informationen i Ladok som en källa för information till omkringliggande system och
behovet av ett öppet system som man enkelt kan integrera mot omgivningen kommer bara att växa. I den nuvarande lösnigen finns det risken med att data kan förvanskas och nyttjas felaktigt då man inte har ett riktigt tillfredställande dataskydd. Tydligare interface för integration behöver definieras; exempelvis kan användning av
text fält i vissa vyer ge ett oväntat resultat då man inte vet vad som kommer över till de kringliggande systemen.
Verksamheten behöver ett kraftigt förbättrar och processorienterat stöd för de mest vanligt förkommande sysslorna. Användarinterfacet, då framför allt i Ladok Nouveau, behöver ses över och helst ersättas med en modernare lösning för att ge ett effektivare och förbättrat stöd för användare.
Möjliga tekniska vägval med nuvarande lösning
De vägval man kan göra med nuvarande plattform är något begränsade i och med den starka bindningen till
Uniface. Även om det i princip går att hänga på mer modern teknik i efterhand tenderar dessa lösningar inte att
bli optimala ur hänseende på prestanda och underhåll. En möjlighet är att man behåller databasen och i övrigt
baserar sin lösning på mer modern teknik. Nackdelen med en sådan lösning är att databasens omfattning är en
del av problemet. En genomgång av databasen där man migrerar data till en ny tabellstruktur och rensar bort
tabeller som bara ligger kvar av historiska skäl skulle ge en databas som är betydligt lättare att underhålla. Bland
riskerna som finns med att bygga vidare på en gammal grund är att man upprepade gånger tvingas ta designbeslut baserade på en omodern teknisklösning vilket kan resultera i att man inte fullt ut kan nyttja den nya tekniken. En annan möjlighet kan vara att på sikt flytta över all funktionalitet ifrån Ladok Nouveau till LpW för att
minska Uniface beroendet, fast i praktiken så innebär ju det att man bygger nytt fast utan möjlighet till den senaste tekniken.
Risker med nuvarande lösning
Enligt Compuwares egna produktutvärdering av Uniface1 så är det största problemet med deras lösning att
4GL/RAD baserade utvecklingsmiljöer är helt ur mode till fördel för kodbaserade miljöer som Visual Studio .Net
och Eclipse. Detta är en helt riktig analys och i takt med att kunderna lämnar plattformen kommer nyutveckling
och underhåll bli lidande. I samma utvärdering påpekar de att även om man fortfarande kan bygga monolitiska
klient/server applikationer så det mest troliga att man vill bygga för webben. Frågan man skall ställa sig är om
man vill bygga vidare på en lösning som i möjligaste mån och vad arkitekturen tillåtigt har anpassats för att göra
något helt annat än vad det ursprungligen utvecklades för eller om man skall välja en lösning som är designad
och utvecklad för att lösa dagens svårigheter inom webbutveckling.
I dagens för föränderliga värld så är det också viktigt att snabbt kunna följa med de förändringar som sker. Väljer
man att bygga vidare på den befintliga Uniface lösningen blir man beroende av att Compuware
1
Compuware Uniface 9 – An ’Product Evaluation’ paper by Bloor Research (Author: Philip Howard)
Version 1.1 – Marcus Gelderman, email: [email protected]
13 / 45
(http://www.compuware.com/) har samma strategiska syn på framtiden. Exempelvis har man i Uniface valt att
ha stöd för Microsofts Mobile Windows som operativsystem i mobila enheter (avancerade mobiltelefoner), vilket
kanske inte så konstigt med ur amerikanskt perspektiv där Mobile Windows är ganska vanligt. Tittar man på
fördelningen av operativsystem i mobila enheter ur ett globalt perspektiv så är Mobile Windows ganska litet med
12% av marknaden och det vanligaste, Symbian OS, dominerar med 65% av marknaden2. Symbian OS används i vissa Sony Ericsson modeller och är också vanligt i Nokias telefoner och de globala siffrorna avspeglar
nog mer förhållandet i Sverige.
Ett annat möjligt problem är datasäkerheten, det nuvarande Ladok-systemet i princip är två system, LpW och
Ladok Nouveau, med delad databas och separerad användaradministration. Den separerade användaradministration gör det svårt att hantera användarna enhetligt och upprätthålla en policy gällande byte av passord och
liknande. Det finns en tydlig risk att även små förändringar blir ganska omfattande uppdrag eftersom det är lite
av ett lappverk. Risken finns också att man skapar små öar med information inne i databasen då tabell strukturen är ganska omfattande och svåröverblickad. I och med att man låter externa processer integrera mot lösnigen via SQL så blir det väldigt svårt, för att inte säga omöjligt att göra tabellförändringar och risken finns att databasen växer till en punkt där det blir väldigt svårt att underhålla systemet då man inte längre har någon överblick över vad som händer vid en eventuell förändring.
Vägande skäl för en teknisk ombyggnad av systemet
Drift och underhåll
Som Ladok ser ut i dag så är systemet lite spretigt med olika program som löser olika problem. I en optimal underhålls situation så byggs systemet på kända och etablerade standarder vilket innebär att man enkelt kan få
del av buggrättningar och uppdateringar och att man kan applicera dessa under kontrollerade former utan att få
överraskningar i form av funktionalitetsbrister. I en lösning där fler separata komponenter utgör systemet som
exempelvis LpW (Ladok på Webb) och Ladok Nouveau är det svårare att se konsekvenserna av en förändring
eller uppdatering. Ytterligare ett problem uppstår i och med att man tillåter varje läroanstalt att göra förändringar
och ha direkt anslutning till databasen. I praktiken måste det vara väldigt svårt för de centrala utvecklarna att
veta att det kommer fungera som det skall för respektive läroanstalt. Ett av de enklare sätten att få ner driftsoch utvecklingskostnaderna är försöka få en så enhetlig miljö som möjligt, se till att systemet har all den funktionalitet man behöver och minska behovet av omgivande produkter.
Likaså uppfyller man idag inte helt de krav på funktion som användarna säger sig vilja ha och stödet för att kunna arbeta processorienterat är i princip obefintligt. Systemet behöver bli mer användarvänligt och lättanvänt. Ett
stöd för rapportgenerering är något som saknas i systemet (Det kan inte vara lätt för läroanstalterna att hitta
duktig administrativ personal som samtidigt är bra på SQL för att kunna generera rapporter).
2
Siffror för mobila OS, Market Share Sales Q4 2007: Symbian OS from Symbian Ltd. - 65%, Windows Mobile from Micro-
soft - 12%, RIM BlackBerry operating system - 11%, iPhone OS from Apple Inc. - 7%, Linux operating system - 5%.
Version 1.1 – Marcus Gelderman, email: [email protected]
14 / 45
Kostnader för licenser
Hela den föreslagna lösnigen bygger på öppen källkodsbibliotek och open source produkter man slipper onödiga licenskostnader och kan välja i vilket utsträckning man vill köpa in support. I och med den flexibla supportmodellen kan man antingen köpa support konsortienivå, driftscentral nivå eller låta respektive läroanstalt själva
välja hur man vill köpa in support; denna möjlighet borde ju innebära goda möjligheter för att förhandla till sig en
kostnadseffektiv lösning.
Kompetensbehov
Lösningsförslaget bygger till viss del på open source produkter, exempelvis JBoss AS, som man redan använder inom verksamheten vilket gör att viss kompetens redan finns att tillgå inom verksamheten. Alla delar av lösningsförslaget bygger på öppna standarder vilket också gör det betydligt enklare att hitta litteratur, utbildningar
och vid behov extern kompetens. Det är också betydligt enklare att hitta och utbyta information i forum på internet när det är stora kända standarder.
Uppfyllande av förändrade omvärldskrav
Med den nuvarande systemlöningen kan man säkert följa omgivningens krav på förändring, men utredaren ställer sig tvekande om detta kan göras med bra systemsäkerhet och utan att lösningen blir ett lappverk av olika
lösningar som var för sig löser något specifikt problem. Andra krav som kan komma att ställas är ökat mobilitet
bland användarna och studenterna kommer att röra sig mer mellan läroanstalterna både inom Sverige men även
utomlands. För att kunna möta detta förändrade beteende så behövs det förbättrade möjligheter till integration.
Om integrationsmöjligheterna skall gå att nyttja effektivt så behövs det ett mer sammanhängande system och
en gemensam meddelande buss som kan nå alla system komponenter. Vidare kommer antagligen det ställas
krav på att kunna nyttja funktionaliteten via terminaler som mobiltelefoner och att information skall skickas via
andra kanaler som exempelvis SMS och för att möta detta krav behövs det en arkitektur som mer effektivt stödjer integration mot omgivande system.
Version 1.1 – Marcus Gelderman, email: [email protected]
15 / 45
Tekniska vägval för en framtida lösning
Visionära möjligheter och enkel teknik för framtiden
Verksamhetens behov av ett enkelt och driftsäkert system ligger till grund för att välja en Java baserad lösning
med. Eftersom man redan inom konsortiet gjort det strategiskt riktiga valet att byta ut Mimer databasen mot
MySQL, samt valt att satsa på Linux som plattform. Även applikationsservern JBoss AS är en produkt som redan är känd inom verksamheten och det finns ingen anledning att inte dra nytta av den kunskap som redan
finns när man valt så starka produkter som grund. Nästa del av förslaget är att ta bort möjligheten till att direkt
ansluta sig till databasen. Även om detta ofta är ett enkelt och snabbt sätt att integrerar system med varandra
så ger det små eller inga möjligheter att effektivt validera inkommande data, man har svårt att utreda hur systemets prestanda fördelas över processerna. En bra integrationslösning med väldefinierade XML meddelanden
och möjlighet att validera dessa mot ett XML Schema skapa en betydlig högre informationssäkerhet. En bra
integrationslösning (ESB) ger även möjlighet till övervakning och spårbarhet av meddelande flöden. Integrationslösningen (ESB) ligger externt utanför systemet och föder Ladok-systemet med data via JMS.
Figur 1: Meddelandet tas emot via Integrationslösningen (ESB) och skickar in det via JMS till
Ladok systemet.
Integrationslösningen (ESB) transformerar inkommande meddelande från de meddelade standarder som man
valt att acceptera. Det inkommande meddelandet klassificeras och loggas. Innan meddelandet läggs på JMS
kön in i Ladok-systemet så transformeras det till XML om det inkommande meddelandet inte var i XML-format
och valideras mot ett XML Schema. Skulle valideringen av meddelandet indikera att något är felaktigt så loggas
detta och ett e-post meddelande skickas till någon som kan åtgärda felet, alternativt skicka det felaktiga meddelandet och felmeddelandet ifrån valideringsprocessen till någon person som är ansvarig för det avsändande
systemet. Väl inne i Ladok-systemet så valideras XML meddelandet igen mot XML Schemat i samband med att
man löser upp meddelandena med JAXB. Valet Integrationslösningen (ESB) behöver inte vara samma för alla
Ladok installationer det kravet som måste uppfyllas är att man kan prata JMS med Ladok-systemet ifrån integrationslösningen (ESB). Rent praktiskt är det givetvis en fördel om även integrationslösningen (ESB) är standardiserad ur ett drifts- och underhållsperspektiv men det kan finnas historiska eller praktiska skäl till att man vill
hålla fast vid en tidigare vald lösning.
Version 1.1 – Marcus Gelderman, email: [email protected]
16 / 45
Figur 2: Ett meddelande skickas in till integrationslösningen (ESB). 1: Loggning, 2: Konvertering 3: Validering 4: Eventuellt skickas ett felmeddelande till någon ansvarig. Om inga fel har
inträffat så skickas meddelandet vidare via JMS in i Lador systemet.
Själva Ladok-systemet är uppdelad i flera skikt (n-tier) där botten skiktet utgörs utav databasen, ett mellan skikt
med JBoss AS som kör Hibernate och de övriga ramverken och som kommunicerar med databasen via JDBC.
I toppen på ligger klientskiktet med HTML och Ajax (Asynchronous JavaScript And XML). Kommunikationen
mellan applikationsserverns/webbservern och klienten sköts via standard http/s, förslagsvis så sitter det en
brandvägg i mellan för att skydda installationen mot intrång. Vill man ytterligare stärka säkerheten kan man även
ha en brandvägg mellan applikationsservern servern och databasservern (Innan man gör några för drastiska
försök att förbättra säkerheten skall man noga analysera vilken hotbild man har mot systemen, risken är stor att
man investerar i fel lösningar utan att ha analyserat vart bristerna i systemet är)
Arkitekturen tillåter möjligheten att skapa ett kluster av applikationsservrar ifall man anser att prestanda eller tillgänglighet inte kan garanteras med endast en uppsättning av maskiner. Vill man förbättra prestanda eller tillgänglighet för databasen kan man nyttja de tekniker som databasleverantören rekommenderar. Vid utveckling
kan hela lösningen komprimeras och utvecklingsmiljön (Eclipse), Webbläsare, Applikationsserver (JBoss), samt
databas server (MySQL) installeras på utvecklarens dator.
Figur 3: Flerskitslösning
Version 1.1 – Marcus Gelderman, email: [email protected]
17 / 45
Webbklient-delen av systemet bör vara baserat på JavaScript och XML (Ajax) och lämpliga ramverk kan vara
JBoss Richfaces (http://www.jboss.org/jbossrichfaces/) SproutCore (http://www.sproutcore.com) eller exempelvis MyFaces (http://myfaces.apache.org/). Vad man väljer här är avhängt hur man vill att kontroller och knappar skall se ut, samt om man har speciella funktionella krav. Beslutet om vilket ramverk som skall användas på
klientsidan behöver vara väl förankrat hos de som kommer utveckla systemet. Tvingar man på utvecklarna ett
klient ramverk som de inte är nöjda med kommer det påverka resultatet negativt och deras upplevelse av klient
ramverket kommer i viss mån sätta tonen för om projektet är lyckat eller inte. Viktigt att förstå är att det finns en
större mängd klient ramverk att välja mellan och vissa av dessa är otroligt effektiva om man använder dem på
precis det sättet som de var tänkta för, om sättet att utveckla eller kravbilden avviker ifrån det optimala användningssättet kan klient ramverket istället bli ett stort problem.
Rätt implementerat kommer användaren uppleva att funktionaliteten hos webbläsaren ligger i samma nivå som
om det hade varit en fet klient installerat på klientmaskinen. I och med att servern har möjlighet att se vilken typ
av enhet eller webbläsare som anropar server så kan man också anpassa det svaret som skickas tillbaka för
den typ av enhet som efterfrågar webbsidan.
Figur 4: Servern anpassar sin vad som skickas som svar beroende på vilken typ av plattform
som är mottagare av informationen.
Version 1.1 – Marcus Gelderman, email: [email protected]
18 / 45
Databasen och själva logiken i bör vara uppsatt på ett sådan sätt att man i samma miljö hantera flera instanser
av Ladok. Detta är väldigt viktigt vid felrättning och utveckling. En utvecklare kan då flytta hela datamängden
från ett system in till sin egen utvecklingsmiljö för att kunna felsöka och testa i en kontrollerad miljö, men med
riktig data. Utöver fördelarna vid utveckling får man flexibilitet att flytta funktionalitet tillfälligt mellan fysiska system vid exempelvis uppgradering eller support på hårdvara, samt att man ges möjligheten att med ganska
enkla medel kan höja prestandan genom att installera ytterligare maskinvara parallellt med befintliga system.
Under utveckling bör enhetstester via JUnit användas för att ge utvecklarna möjlighet att verifiera och validera
funktionaliteten i systemet. Samtidigt får man inte glömma att ta höjd för riktiga definierade funktions och integrationstester. Enhetstester är ett bra verktyg för utvecklaren att testa funktionalitet men inget säkert sätt att testa
system på. För att underlätta utvecklarnas arbete bör man dra nytta av ramverk som Spring Framework
(http://www.springframework.org/). Utvecklingsplattformen Eclipse (http://www.eclipse.org/) är en av de absolut
bästa på marknaden och även den är open source och gratis att nyttja. Eclipse är plugin-baserad och det finns
en uppsjö med plug-in:er för att utöka funktionalitet eller förbättra stödet för exempelvis JBoss AS. Eclipse har
ett bra stöd för kod revisionshantering och i lite större projekt med fler än en deltagare är det ett absolut måste
med en centraliserad lösning för kod revisionshantering. Om man inte redan har valt något system för kod revisionshantering så är Subversion ganska enkelt att använda och få igång. En fördel med Subversion är att all
meta information om revisionerna ligger på hårddisken tillsammans med koden och vid backup räcker det med
att man gör en kopia på directory strukturen på servern för att få med allt. Vissa mer avancerade lösningar kan
vara rätt svåra att göra backup på. Subversion fungerar för ett flertal Linux- och Unix-miljöer och finns att hämta
ifrån http://subversion.tigris.org/.
Ett viktig användningsområde som man inte får missa är möjligheterna att generera rapporter ifrån Ladoksystemet. I den nuvarande Ladok-lösningen har de som jobbat med systemet kunnat knåpa ihop några rader
SQL och kört frågan mot databasen. Att köra SQL mot databasen är tekniskt möjligt även i det nya lösningsförslaget, men inte önskvärt utav fler skäl. Kör man SQL mot databasen är det väldigt svårt att kontrollera vilka resurser som krävs för att svara på frågan; en klumpigt ställd SQL-fråga kan skapa låsningar och prestanda problem i nästan vilken databas som helst. Ställer man dessutom SQL-frågor mot en databas som kontrolleras av
Hibernate så passerar frågan utanför hela Hibernate ramverket och man kan inte dra nytta av de mekanismer för
ökad prestanda som Hibernate erbjuder, som exempelvis cache och optimerings funktionalitet. Lösningen för
att behålla flexibiliteten i SQL samt dra nytta av fördelarna hos Hibernate är att använda Hibernates egna SQL
liknande språk HQL. Om man är duktig på SQL är det inget stort steg att förstå och skriva HQL. En annan lösning är att man lägger tid och energi på att utveckla ett rapportverktyg som ger användaren möjlighet att skapa
egna frågor mot datamängden via ett webbinterface. Verktyget bör även ge möjligheten att spara frågor både
lokalt bara för mig som användare och system globalt ifall jag vill dela med mig av mina mer lyckade HQL frågor.
Rapportverktyget behöver dessutom ge en möjlighet att exportera som Excel- och XML-format för export till
andra verktyg där man vill ha möjlighet att processa data ytterligare. En möjlig produkt att använda här skulle
kanske kunna vara Jasper Reports (http://www.jaspersoft.com/) eller något liknande.
Ny datamodell och migration
I den nuvarande Ladok-lösningen så är det problem med att attribut använd även som nycklar. Detta skapar
problem vid exempelvis byte av personnummer. I samband med ett systemskifte så behöver databasen se över
och förslagsvis börjar man ta höjd för datamigration redan vid utvecklingsstart. Ett sätt att adressera detta är att
Version 1.1 – Marcus Gelderman, email: [email protected]
19 / 45
man använder sig av data som kommer ifrån det befintliga systemet redan under utveckling och att man bygger
funktionalitet för datamigration samtidigt som man utvecklar den nya funktionaliteten.
Exempelvis skulle arbetsflödet kunna gå till så här:
1. Identifiera ett begränsat område som man vill migrera (Lättast är det om man kan ta bit för bit av funktionaliteten)
2. I den befintliga lösningen identifierar man de tabellerna som innehåller den data man behöver.
3. Skapa Java-objekten som kan hantera data från den befintliga lösningen och lägg till egna nyckelbegrepp till objekten och var noga med att använda rätt Java-typer; exempelvis Integer osv.
4. Låt Hibernate genererar de tabeller som behövs för att spara Java-objekten ifrån punkt 2.
5. Undersök hur databasen blev skapad och upprepa punkt 3 – 5 tills man uppnår ett tillfredställande resultat.
6. Skriv kod som via en SQL anslutning kopierar (migrerar) och in till de Java-objekten man skapat och låt
Hibernate spara objekten i databasen. Se även till att göra en typ konvertering mellan data så exempelvis numerisk data blir konverterade till Java typerna Long, Integer eller motsvarande
7. Validera att data i de nya tabellerna ser ut som förväntat, upprepa punkt 6 – 7 och eventuell punkt 3
och framåt tills ett tillfredställande resultat har uppnåtts.
8. Bygg de grafiska gränssnitt som behövs för att kunna se och editera data som migrerats. Upptäcker
man något saknas eller är fel upprepar man processen ifrån punkt 2 och framåt.
9. Bygg enhetstester för att kunna validera funktionaliteten.
Följer man schemat ovan så kommer man i slutändan har all den generella kod som behövs för att migrera databasen. Man kommer ha konverterat data till dess naturliga format, samt ha tester att validera funktion och
data. Ett problem kan vara de lokal variationer av databasen som existerar och där får man ta höjd för detta genom att göra anpassningar i den generella lösningen för att täcka dessa lösningar. Målet är att få en generell
databas modell för alla Ladok-system och lokala avvikelser skall undvikas i mesta möjliga mån. Ur ett underhållsperspektiv blir det väldigt kostsamt att underhålla ett flertal system med små lokala skillnader och risken är
överhängande att man får problem vid gemensamma uppdateringar av systemet.
Version 1.1 – Marcus Gelderman, email: [email protected]
20 / 45
Krav på drift och underhåll
De tekniska drifts- och underhållskraven på Ladok skiljer sig inte nämnvärt ifrån andra webb-baserade system.
Det som framför allt är viktigt är att hålla kostnaderna nere så mycket som möjligt och det bästa sättet är att
man göra systemen för respektive läroanstalt så lika som möjligt. Förslaget att ett Ladok-system skall kunna
hålla olika instanser av Ladok för olika lärosäten ger driftsorganisationen möjlighet att konsolidera flera system
på samma hårdvara kan vara ett sätt att underlätta för driftsorganisationen och spara pengar på.
En möjlighet som ligger lite utanför själva Ladok-systemet är att nyttja virtuella servrar. Systemuppsättningen blir
snarlik eller samma som beskrivet i detta dokument, men skillnaden ligger i att istället för att installera på Linux
hårdvara så installeras miljöerna i virtuella maskiner. Fördelen ligger i att i den virtuella miljön finns ingen koppling
till hårdvaran och det är helt upp till drift personalen att fördela prestanda, diskutrymme och andra resurser till de
virtuella miljöerna. Möjligheterna öppnas att nyttja resurserna i datahallarna mer effektivt och man brukar kunna
spara pengar på att mindre mängd el går åt att driva och kyla maskinerna. Grön IT innebär ju även vinster utanför datorhallen som kan var önskvärda.
Framtida kompetensbehov
I det lösningsförslag som tagits fram ligger kompetens tonvikten på Java, JavaScript, Ajax, JBoss AS, Hibernate, XML Schema, XML och Spring framework detta är stora öppna standarder och kunskapen som förvärvas
under utvecklingen går utmärkt att använda i andra webbaserade projekt. Denna kunskap är inte heller något
problem att köpa in externt. Väljer man att inte uppdatera Ladok till en ny systemgeneration kommer man fortsättningsvis ha ett krav på Uniface-kompetens som kan vara svårt att uppfylla externt.
Version 1.1 – Marcus Gelderman, email: [email protected]
21 / 45
Säkerhet och tillgänglighet
Tillgänglighet
Den nuvarande lösningen
De tillfrågade anser sig inte se något problem med prestanda och tillgänglighet i det befintliga systemet. Lösningen där man replikerar databasen till Ladok Open och ställer frågor mot Ladok Open fungerar tillfredställande
för den belastning som man ser att man har inom en när framtid.
Framtida krav på tillgänglighet
Om man väljer att låta studenterna administrera sig själva i större utsträckning än innan och samtidigt som man
gör systemet mer attraktivt i form av utökad funktionalitet kommer ganska snart kraven på tillgänglighet ligga
dygnet runt, 24-7. En viktig faktor som måste förstås med webbaserade system är att kraven på prestanda
måste kunna möta den momentant högsta belastningstoppen. I batch-orienterade system har man ofta möjligheten till återhämtning efter en momentan belastningstopp. Om det uppstår prestanda problem i en webbbaserad lösning påverkar det allt processande och genererar i regel ännu större prestandaproblem då användarna i
ren irritation trycker ännu fler gånger på knapparna eftersom inget händer. Den möjligheten till återhämtning sker
när användarna tröttnat på att vänta och lämnar webbplatsen. Det vanligaste sättet att bygga för belastningstoppar är att man identifierar den mest hektiska perioden för verksamheten och beräknar belastningen efter den.
I praktiken betyder det att har man sin belastningstopp mellan nio och tre måndag till fredag eller om december
månad är den mest hektiska så är det denna belastning som bestämmer storleken på systemet. Problemet med
att dimensionera efter topparna är väldigt tydliga i de fall då man har hög belastning under ett fåtal dagar eller
någon månad per år och men ändå tvingas betala för den utrustning som krävs för att hantera topparna.
En möjlig lösning på detta kan vara att basera lösningen på virtuella maskiner och hitta en passade capacity-ondemand (COD) leverantör. En annan möjlighet är att man delar server- och bandbreddskapacitet med något
företag eller organisation som har samma problem, men där toppar ligger annorlunda ur ett kalender- eller
dygnsperspektiv.
Identifierade risker
För att undvika prestandaproblem så bör man redan från första början vara noga med att identifiera vilka flaskhalsar som existerar i systemet, samt att tidigt börja nyttja prestanda höjande tekniker som klustring av servrar.
De flesta leverantörer av mjukvara respektive hårdvara har tips på hur man optimalt nyttjar deras produkter.
Bygger man med prestandakraven och möjlighet till skalning i åtanken behöver detta inte bli något stort problem.
Version 1.1 – Marcus Gelderman, email: [email protected]
22 / 45
Datasäkerhet
Den nuvarande lösningen
Den nuvarande lösningen har lite varierande nivå på datasäkerheten och särskilt när det gäller kommunikation
mot Ladok Nouveau finns det möjligheter att kommunikation kommer att gå okrypterad. För att åtgärda denna
brist så nyttjar man bland annat en Citrix-lösning. I och med att de olika system delarna som LpW, Nouveau,
och Ladok Connector både samverkar och är separata är det viktigt att förstå att en splittrad miljö i sig är en risk
för framtiden och en extra utvecklingskostnad idag.
Framtida säkerhetskrav
I och med att man hanterar allt ifrån publika uppgifter till uppgifter rörande skyddade identiteter måste lägsta
nivå av säkerhet sättas så att även de publika uppgifterna hanteras på samma sätt som de skyddade identiteterna. All kommunikation bör vara krypterad mellan webbläsare och server, liksom all WebService kommunikation bör vara krypterad. När det gäller meddelanden som skicka till och ifrån system så bör man klassificera in
informationen i olika nivåer och kryptera den information som bör vara krypterad. Anledningen till att man inte
generellt kan kryptera all information är att det troligtvis kommer finnas ett behov av att kommunicera med kringliggande system där man gjort bedömningen att informationen inte behöver krypteras och det då skulle bli ett
problem att man ifrån Ladoks sida ställer kravet att all information skall vara krypterad.
Identifierade risker
Att någon obehörig kommer åt information från systemet är otroligt allvarligt i och med att det skapa en förtroende kris för hela systemet. Problemet växer i och med att Ladok lagrar känslig information som kan skapa en
stor skada i fel händer. Bara det faktumet att det är svårt att avgöra hur bra säkerheten faktiskt är i den befintliga
lösningen är skäl nog för att se över hela systemet.
Åtkomstkontroll
I den nuvarande lösningen har man nyttjat möjligheten till Singel Sign On för de användare som ansluter via
LpW. För de expertanvändare som ansluter via Ladok Nouveau sker användare hanteringen internt i systemet
och användarna ligger definierade i en tabell i databasen. Ladok Nouveau-autentiseringen kan även ske via
X.509-certifikat. Det är enligt utredarens mening inte helt praktiskt att ha två typer av användare där den ena
ligger definierad i databasen och den andra utanför systemet. För att man säkert och enkelt skall kunna administrera alla användare centralt så bör dessa bara finnas definierade på ett ställe.
Framtida krav för åtkomstkontroll
Oavsett lösning för autentisering så kommer det behövas ett rollbaserat behörighetssystem. Enligt det förslaget
som jag lägger fram så kommer information att läsas och skrivas via tre olika vägar. Antingen kommer omgivande system att prata med Ladok-systemet via en Web Service-lösning, en del information kommer att gå via ESB
(Enterprise Service Bus) och slutligen via användarnas interaktioner på webben. Gemensamt för alla dessa inVersion 1.1 – Marcus Gelderman, email: [email protected]
23 / 45
formationsvägar är att man inte kan lita på dem utan man behöver veta vem som frågar och vad man frågar om.
För att göra detta enkelt så klassificerar man in de olika händelserna i roller; exempelvis kan en Web Service
förfrågan från en lokal maskin gällande uppgifter av väldigt allmän art vara sådan att den kommer in okrypterad
och oautentiserad och ges den process i systemet som skall utföra frågan en roll som gör att den bara kan
komma åt oskyddade uppgifter i systemet. Om samma maskin ställer en ny fråga, denna gång över en krypterad uppkoppling t ex via Transport Layer Security (TLS) eller Secure Sockets Layer (SSL) och samtidigt skickar
med någon form av autentisering så tilldelas en helt annan roll till den processen som skall ställa frågan emot
systemet och databasen.
Identifierade risker
I den nuvarande lösningen är det svårt att få en överblick av användarna eftersom de kan definieras i det externa
behörighetssystemet eller i databastabellerna. För att effektivt kunna administrera alla användare så bör de vara
definierade på samma ställe.
Version 1.1 – Marcus Gelderman, email: [email protected]
24 / 45
Framtida möjligheter
Singel Sign On (SSO) och autentisering utanför systemet
En av de enklare men ganska viktiga teknikerna som många tittar på idag är ”Singel Sign On” (SSO), dvs. att
användaren endast autentiserar sig en gång och sedan har sin behörighet till de system som använts utan att
behöva autentisera sig ytterligare. SSO ses ofta som en ren komfortfråga för användarna, men kan faktiskt vara
ett av det enklare och mer praktiska sätten att höja intrångssäkerheten i systemen radikalt. Om man väljer att
implementera SSO så har användarna bara en lösenordspolicy att ta hänsyn till och man kan kräva lite högre
krav på utformning av lösenord och hur ofta det skall bytas. För användarnas del brukar det vara enklare att
acceptera att man har ett något krångligare lösenord om det dels bara behöver användas en gång per session
och det är det enda som man behöver hålla reda på när man arbetar med systemen.
I dagens system skulle detta kanske gå att lösa genom att bygga på en lösning där man översätter det som
symboliserar en autentiserad användare till ett användarnamn i Ladok systemet. Ett problem med att bygga på
en lösning på det befintliga systemet är att man fortfarande har kvar infrastrukturen i systemet och det kommer
kräva underhåll ifrån användaren sida vid exempelvis byte av lösenord och liknande. En annan fara är att man
missar eller underlåter sig att byta passord i systemet och på så sätt skapa en falsk trygghet där man tror att
man har en hög säkerhet i och med att SSO-autentiseringen uppfattas som säker.
De generella fördelar man brukar se med SSO är:
•
Färre samtal till supporten på grund av glömda passord.
•
Kortare tid läggs på att logga in i systemen.
•
Passorden återanvänds inte i samma utsträckning och upprepas inte ifrån system till system
•
En gemensam policy för hur passorden skall se ut.
Väljer man att implementera SSO skall man vara noga med att se till att den lösningen man väljer stödjer minst
Microsoft Active Directory, Kerberos baserad inloggning, UNIX/Linux PAM inloggning och troligtvis vill man även
kunna hantera OTP (One-Time Password) RSA SecurID och Smart card baserad inloggning.
Elektronisk id och autentisering av studenter
När det gäller autentisering av studenterna så ser kravbilden lite annorlunda ut. Man kan i de flesta fallen utgå
ifrån att studenten har tillgång till någon form av elektronisk id utfärdad av dennes bank. Även om verifiering av
BankID är ganska tekniskt knöligt i dagsläget så är ju det fullt möjligt att centralisera denna funktionalitet så att
alla läroanstalter använder ett gemensamt system för autentisering. BankID har en stor fördel och det är väl utbredd och läroanstalten slipper själv lägga energi och tid på att verifiera att personer är de, de ut ger sig för att
vara. BankID lösningen behöver kompletteras men en lösning för utländska studenter som inte av någon anledning har ett bankkonto i en svensk bank. Andra möjligheter kan vara det av Yale University utvecklade Central
Authentication Service (CAS - http://www.ja-sig.org/products/cas/ ) för autentisering. En annan möjlighet som
Version 1.1 – Marcus Gelderman, email: [email protected]
25 / 45
ofta används är autentisering via engångskoder skickade till mobiltelefonen. Nackdelen med detta är att det kräver att man registrerat sitt mobilnummer i förväg och man har en mobiltelefon.
Om man väljer att bygga Ladok-systemet så att det kan hantera autentisering utanför det egna systemet så
finns det egentligen ingen gräns för vad man kan välja för typer av autentisering.
Rollbaserad säkerhet
Ett rollbaserat säkerhetssystem bör byggas för att stärka säkerheten i systemet. Beroende på vad din uppgift är
i systemet, samt hur du har autentiserat dig bör ge en säkerhetsklass eller en roll. Vad man kan utföra i en viss
roll är förutbestämt i Ladok och vilka roller man får bestäms vid inloggningen beroende på vilken typ av användare du är, samt hur du valt att autentisera dig för system.
En användare som loggar in via webben med användarnamn och lösenord kanske inte skall få lämna uppgifter
till systemet utan bara läsa. Samma användare kanske senare på eftermiddagen loggar in med sitt smart card
via datorn på institutionen och hamnar då i en annan säkerhetsklass och har då möjlighet att ändra uppgifter i
systemet.
SPOCP (Simple Policy Control Project - http://www.spocp.org/ ) är ett samarbetsprojekt mellan fem svenska
universitet, Karolinska Institutet, Lunds Universitet, Stockholms Universitet, Umeå Universitet och Uppsala Universitet och Uninett, the Norwegian National Research Network. SPOCP kan mycket väl vara en bra lösning för
att hantera rollbaserad säkerhet. SPOCP nyttjas redan i viss utsträckning i nuvarande version av LpW så kunskap finns i viss mån redan i organisationen, vilket kan vara en fördel.
Rätt hanterat är rollbaserad säkerhet relativt enkelt att administrerar och man kan enkelt hantera rättigheter för
stora grupper på en gång. Ser man till att göra ett tydligt gränssnitt för den egna kod som hanterar autentisering
och roller så kan ett eventuellt byte det externa system som hanterar autentisering och roller vara fullt möjligt ifall
man i efterhand inser att man valt fel. Viktig här är att man i det egna systemet implementerar de delarna som
hanterar autentisering och roller väldigt generiskt och med ett plug-in tänk.
Kryptering, Certifikat och digitala signaturer
Digitala signaturer och kryptering av data är i dag en viktig faktor för att säkerställa att informationen är oförvanskad och i samma skicka som när den skickades. I en värld där man mer och mer litar på de digitala uppgifterna blir det mer och mer viktigt att man skyddar dess uppgifter på ett bra och riktigt sätt.
Programmeringsspråket Java har mycket goda möjligheter till både kryptering och digitala signaturer och det är
ganska enkelt att nyttja dessa API: er. När det gäller kryptering så är också det vikigt att man enkelt kan byta
algoritm men mycket kort varsel; anledningen till detta är att datortekniken går så snabbt framåt att en algoritm
som anses som väldigt säker idag kan anses har kraftiga säkerhetsbrister inom en väldigt nära framtid. Ett problem med den nuvarande lösningen där Ladok Nouveau kör på Uniface plattformen är att även om man nyttjar
Uniface möjligheten att anropa Java kod riskerar att få underhålla två olika kodbaser för kryptering, detta gör att
uppdatering och eventuella byte av krypterings algoritm kan bli onödigt avancerade operationer.
Version 1.1 – Marcus Gelderman, email: [email protected]
26 / 45
Nationella och internationella tekniska samarbeten
Framtida möjligheter
På samma sätt som i den övriga världen har man i universitetsvärlden sett de ökade möjligheterna med integration. Värdet av det egna systemet blir större om det kan kommunicera med omvärlden. Den traditionella lösningen för integration är att man bygger unik lösning för varje system man vill kommunicera med drar nytta av
den teknik som finns tillgänglig. Vanligtvis leder detta till att man får en svår överblickad lösning och någon form
av applikationsspagetti.
Figur 5: Applikationsspagetti
Krav på en framtida lösning
Den framtida lösningen tillåter inte direkt access till databasen, tydliga interface är definierade för att läsa och
skriva information till databasen. I och med att interfacen är metodbaserad kan man tydligare definiera vad som
skall hända när de anropas. Information utbyts antingen via ett Web Service anrop för mindre datamängder och
enklare funktioner eller via ett XML-baserat meddeladeinterface. De XML-baserade meddelandena av krypteras
vid behov och valideras mot ett XML Schema för att säkerställ att informationen och syntax är riktig. Innan informationen har nått Ladok-systemet har det passerat integrationslösningen (ESB) som också har validerat data
och syntax och eventuellt har konverterat meddelandet ifrån någon av de meddelande typer som man tillåter.
Integrationslösningen (ESB) har också loggat meddelandet för spårbarhet och i händelse av att något är fel med
meddelandet så har det loggats och en rapport har skickat till någon som kan åtgärda felet.
En annan fördel med integrationslösningen (ESB) är att man centraliserar kopplingarna till en punkt och man har
en betydligt bättre överblick. I och med att man valt en eller ett fåtal produkter att jobba med så har behöver
man inte sprida kunskap över ett flertal olika tekniska lösningar och de som skall utveckla applikationer för valideringar och/eller konvertering har bättre förutsättningar att återanvända lösningar.
Version 1.1 – Marcus Gelderman, email: [email protected]
27 / 45
Figur 6: En integrationslösning centraliserar kopplingarna
Möjligheter i den nuvarande lösningen
I den nuvarande lösningen finns det en början till en integrationslösning och tankarna finns där i form av Ladok
Connector. Tyvärr är väl arkitekturen inte optimal för en enkel lösning. Ett problem som kommer att uppstå är
när man har behov av nära realtidsintegration och behöver informera eller uppdatera en användare eller process
om att ny information finns tillgänglig i databasen. Det finns inget enkelt sätt att få databasen att informera de
överliggande lagren om att ny data finns tillgängligt och den vanligaste lösningen bygger på att man regelbundet
läser tabeller i databasen för att se ifall det kommit ny information. Detta problem är inget specifikt för Ladok
utan är ett resultat av arkitekturen.
Datastandarder
Meddelanden som skickas och tas emot brukar vanligtvis i något av följande format ANSI X.12 (USA), EDIFACT
(Europa), XML (Hela världen), Eget inhouse format (Hela världen). En bra integrationsplattform har stöd för dessa
format och i praktiken är det underordnat i vilket form meddelandena kommer att komma in i. Integrationsplattformen kommer att kunna göra en formatkonvertering av meddelandet till ett format som används av de bakomliggande systemen. I dagsläget är det troligt att krav på student- och kursinformation kan utväxlas ganska fritt
mellan de olika utbildningssystemen. Med tiden så kommer krav på ökad utväxling av information och möjligheten att styra i vilken format data kommer kan vara svårt. Viktigt är att ta höjd för att man kommer få hantera
udda datastandarder, samt se till att välja en integrationsplattform som är flexibel nog att hantera dem.
Version 1.1 – Marcus Gelderman, email: [email protected]
28 / 45
Internationella samarbeten
När man tittar på de internationella samarbetena som exempelvis Metadata for Learning Opportunities (MLO),
CDM, EMIL, eduCourse är dessa oftast XML baserade, samtidigt håller XML på att bli det vanligaste formatet
vid nyutveckling, detta gör att man bör fokusera på en integrationsplattform med bra stöd för XML.
Ladok systemet själv kommer troligtvis ha ett behov att kunna utväxla studieresultat och information om genomgångna kurser för att förenkla administrationen när studenten vill ta ut sin examen.
Version 1.1 – Marcus Gelderman, email: [email protected]
29 / 45
Beslutskriterier för ombyggnad och kostnadsaspekter
Beslutskriterierna för ett beslut om ombyggnad
Att besluta om eller när ett system behöver bytas ut eller förnyas är alltid svårt. I denna utredning så har utredaren försökt lyfta fram punkter till förbättring och påvisa risker med den nuvarande lösningen, men hur skall man
veta att det är dags för förnyelse eller om det är okey att stanna kvar i den gamla lösningen ett tag till? För att ge
en hjälp på vägen så har utredaren tagit fram några punkter att reflektera över.
•
De nya ramverken för webbapplikationer öppnar för en långsiktigt hållbar och expanderbar arkitektur
och sänker kostanden för drift. Det faktum att vi närmar oss en standard för hur en webbapplikation av
den här storleken skall byggas och hur de skall fungera ger en säkrare framtid och en större långsiktighet i investeringen.
•
Compuware uppger själva att deras Uniface-plattform inte längre är modern – ”Arguably the biggest difficulty that Compuware faces with respect to Uniface is that development environments with a
4GL/RAD ancestry have fallen out of fashion.” Även om Compuware själva anser att detta är ett misstag och anser att plattformen har ett fortsatt existensberättigande så är Compuware affärsdrivande och
kommer att fasa ut produkter som inte generera pengar. Upplevs plattformen som föråldrad kommer
det till slut bli självuppfyllande och plattformen är att betrakta som föråldrad. Att göra nyinvesteringar i
en föråldrad plattform innebär med god säkerhet att man får ta kostnaden ytterligare en gång och då i
samband med att man byter plattform.
•
Genom att röra sig mot nyare tekniker och mer generella ramverk och fokusera på Enterprise Java
(J2EE) så är det enklare att hitta kompetens. Det finns en risk att fastna med en teknik som är dyr att
hitta kompetens inom.
•
Den nuvarande databaslayouten är så omfattande att det kommer leda till problem och i framtiden. Genom att migrera och objektifiera (via Hibernate) data i databasen så tvingas man reda ut problematiken.
Det blir betydligt lättare att identifiera de personer med historiken kring databasen om man inte väntar
för länge.
Kostnadsaspekter
Utredaren har valt att avstå ifrån att göra direkta kostnadsuppskattningar. Anledningen till detta är att dels att
licensavgifter, drifts- och underhållskostnader för den befintliga lösningen inte varit kända för utredaren under
pågående utredningen, dels att arbetet med att sätta upp en tidplan och beräkna kostnader för nyutveckling
inte varit en del av uppdraget. Att i förhand beräkna kostanden för nyutveckling inom områdena som berör databasen kan bli svårt och kan kräva att man gör en liten förstudie där man migrerar lite data på prov och ser
vilken omfattning på arbete som krävs.
Version 1.1 – Marcus Gelderman, email: [email protected]
30 / 45
T e k n i s k a b i l a go r
Hibernate
Summering
Hibernate är lösningen på problematiken att spara objekt (persistens), i detta fall Java-objekt, i en relationsdatabas för att uppnå så stora fördelar som möjligt ifrån båda världarna. Object Relational Mapping (ORM) heter begreppet och i praktiken är det ett system som omvandlar data som ligger i en eller ett flertal tabeller i databasen
till ett Java-objekt. ORM omfattar även begreppet persistens; den mekanism/teknik som gör att data spara på
ett säkert sätt och på ett annat medium är i själva minnet. Det finns andra lösningar en Hibernate, men Hibernate är den populäraste lösningen och i min mening den bästa lösningen för ORM i dagsläget. De vanligaste lösningarna utöver Hibernate är Enterprise Java Beans (EJB) och CMP entity beans/BMP entity beans, Java Data
Objects (JDO) alternativt en egen lösning med hjälp av JDBC och egen java kod. Alla dessa tekniker kan ha någon fördel jämfört med Hibernate men ser man till hela helheten så är Hibernate i regel den bästa lösningen.
Hibernate fungerar tillsammans med alla stora produkter på marknaden och alla populära open sourcelösningar. Hibernate själv är utvecklat som open source och finns att hämta på nätet ifrån
http://www.hibernate.org.
Hibernate i princip
Principen för Hibernate är ganska enkel, helt vanliga Java objekt (POJOs – Plain Old Java Objects) serialieras i
databasens tabeller enligt det reglerverk man beskrivit i konfigurationen för Hibernate. Alla förändringar i databasen sker via Hibernate och Hibernate genererar själv den SQL som behövs för att stödja de frågor och förändringar som utvecklaren vill göra. Utvecklaren behöver i princip bara tänka på hur man skall hantera Javaobjekten och lämna persisteringsfrågan åt Hibernate. Den SQL Hibernate genererar är i regel väldigt effektiv,
men skulle man ha ett krav på att en fråga måste ställas på ett visst sätt är det möjligt att skriva egen SQL för en
fråga. I och med att SQL:en genereras dynamiskt (…och vanligtvis vid systemstart) så är det möjligt och inte alls
en allt för svår operation att byta databas efter att systemet har utvecklats. Hibernate har också stöd i en del
utvecklingsmiljöer som t ex Eclipse och med hjälp av plug-in:er kan man få en närmare koppling till miljön under
utvecklingsfasen. Hibernate går också utmärkt att integrera med de flesta test och utvecklingsmodeller och använder man exempelvis JUnit under ”normal” utveckling går det utmärkt att fortsätta med det även i ett Hibernate projekt.
Hibernate är byggt ovanpå en del kända Apache open source-projekt och hämtar en del av sin funktionalitet
ifrån Apache Commons-projekten. Hibernate nyttjar också en del open source-projekt från caching av objekt
(cacha – att temporärt spara objekt i ett snabbt åtkomligt minne), vilket gör det möjligt att välja vilken ”cache
provider” man vill ha (…eller ingen alls om man inte bryr sig om prestanda). Denna möjlighet att välja cache innebär att man exempelvis kan välja en distribuerande cache-implementering och på så sätt fördela prestanda
Version 1.1 – Marcus Gelderman, email: [email protected]
31 / 45
över ett flertal installationer eller att man efter att systemet tagits i drift har möjlighet att genom konfiguration
ändra till en lösning som kanske är mer lämpad för den uppgiften som skall lösas. Viktigt att nämna här är att i
och med att Hibernate kommunicerar helt vanlig JDBC med databasen så fungerar det i de flesta fall alldeles
utmärkt att nyttja de prestanda höjande lösningarna som databas tillverkaren redan erbjuder i sin lösning tillsammans med Hibernate.
Figur 7: Hibernate systembild
Prestanda och Hibernate
Om man har satt upp Hibernate riktigt, använder en cache som passar lösningen rimligt och har skrivit Java-kod
som är rimlig så skall man förvänta sig en prestanda som ligger i paritet med vad JDBC skulle ha gjort. Den
SQL-kod som genereras av systemet är väldigt effektiv och det är väldigt få utvecklare som skulle få till en lika
effektiv kod om de väljer att skriva egen SQL. Anser man att prestandan ligger under vad JDBC skulle ha gjort
så skall man nog undersöka hur arv och mappningar av Java-objekten ser ut i koden. Anser man ändå att man
kan skapa bättre prestanda med egen SQL eller har ett problem som inte går att lösa med det inbyggda frågespråket HQL (Hibernate Query Language) så hindrar inte Hibernate en ifrån att blanda in egen SQL om man så
vill; Priset av att använda SQL i Hibernate är att om man skriver databas specifik SQL så förlorar man möjligheten att väldigt enkelt byta ut den underliggande databasen och blir tvungen att skriva om den SQL som man
gjort för att får den att passa en eventuell ny databas dialekt av SQL och eftersom objekt cache:en hanterar
Java-objekt kommer man inte kunna nyttja cache funktionaliteten för den SQL kod man skrivit (…troligtvis blir
priset också sämre prestanda och/eller ett sårat ego hos ännu en utvecklaren som konstaterat att han/hon inte
skrev bättre SQL än en maskin)
Version 1.1 – Marcus Gelderman, email: [email protected]
32 / 45
Att förstå Hibernate
Att lära sig Hibernate kan vara lite svår och en del av tiden går åt att förstå hur objektgrafen ser ut vid ett givet
tillfälle och hur den kommer att se ut efter förändring (objektgrafen är den tänkta bild man skulle få om man ritade ut alla objekt och deras relation med varandra vid en given tidpunkt) och en stor del av den kritik som
Hibernate har fått bygger ofta på att kritikern inte riktigt har förstått hur Hibernate fungerar eller när det är en
lämplig teknik. Det är av största vikt att man lägger tid och energi på att lära sig hur Hibernate fungerar om
projektet skall bli lyckat.
Hibernate-kunskap
För hjälp att lära sig Hibernate finns det kurser man kan gå, dessa kurser hålls i USA eller i Europa, men tyvärr
har jag inte sett någon som har hållits i Sverige. Utöver kurser så finns det en väldigt bra bok; ”Java Persistence
with Hibernate” (Christian Bauer & Gavin King; ISBN10: 1932394885 ISBN13: 9781932394887) som är skriven
av de som ursprungligen utvecklade Hibernate och den fungerar även som referensverk. Vill man pröva och
stegvis lära sig hur det fungerar så finns det även en något äldre bok som på ganska enkelt sätt beskriver de
första stegen in i Hibernate världen; ”Hibernate: A Developer's Notebook” (James Elliott; ISBN10: 0596006969
ISBN13: 9780596006969). Utöver dessa böcker finns det ytterligare några fler skrivna i ämnet, samt ett hyfsat
forum där man ges möjlighet att ställa frågor och om man har tur få ett bra svar.
Snabbsummering för- och nackdelar
Bra
•
Skapar ett oberoende till databasleverantören, ger möjlighet att byta databas relativt enkelt
•
Ger möjlighet till centraliserad och enhetlig konfiguration
•
Förkortar utvecklingstiden (när man förstår hur Hibernate fungerar)
•
Den del av koden som hanterar persistents blir mindre komplex.
•
Systemet blir relativt enkelt att underhålla och uppgradera i tack med ny teknik kommer.
Dåligt
•
Lite hög inlärningströskel
•
Arvsmodellen kan vara svår att förstå
Version 1.1 – Marcus Gelderman, email: [email protected]
33 / 45
JBoss Application Server (JBoss AS)
Summering
JBoss AS är en open source-baserad applikationsserver. JBoss AS uppfyller de krav som man kan ställa på en
full Java EE (Java Platform, Enterprise Edition) implimentation. JBoss AS går utmärkt att köra på de flesta operativsystem där ibland Mac OS X, Linux eller Microsoft Windows. JBoss AS kräver en Java miljö version 1.4 senare (rekommendationen vid nyutveckling idag är att minst välja version 1.5 av Java). JBoss AS skalar bra mellan
olika miljöer och är relativt snabb när man nyttjar den som utvecklingsmiljö. Den öppna licensmodellen innebär
att man enkelt kan förse alla utvecklare med komplett utvecklingsmiljö på den egna maskinen utan några licenskostnader för applikationen. I och med att JBoss AS är den applikationsserver som använts för LpW så finns ju
en del kunnande redan inom organisationen, skulle det inte räcka så går det utmärkt att köpa support (exempelvis från Redpill http://www.redpill.se). JBoss AS är en erkänd och välanvänd applikations server vilket innebär
att det finns ett flertal konsulter i Sverige som kan erbjuda sina tjänster mot plattformen. Den öppna licensmodellen är också en ekonomisk faktor och kanske en möjlighet att krympa kostnaden för licenser och support.
Standarder och tekniker som stöds av JBoss AS
•
Clustering
•
Failover (including sessions)
•
Load balancing
•
Distributed caching (using JBoss Cache, a standalone product)
•
Distributed deployment (farming)
•
Enterprise Java Beans version 3
•
Aspect-Oriented Programming(AOP)-support
•
Hibernate-integration (for persistence programming;JPA)
•
Support for J2EE-Web Services like JAX-RPC (Java API for XML for Remote Procedure Call)
•
Java Message Service integration
•
JCA (Java Connector Architecture)-integration
•
JACC (Java Authorization Contract for Containers)-integration
•
EJB 2.1-specification
•
JSP/Servlet (Tomcat)
•
RMI-IIOP (JacORB, alias Java and CORBA)
•
JTA (Java Transaction API)
•
JDBC
•
SAAJ (SOAP with Attachments API for Java)
•
JNDI (Java Naming and Directory Interface)
•
JAAS (Java Authentication and Authorization Service)
•
JavaMail
Version 1.1 – Marcus Gelderman, email: [email protected]
34 / 45
•
Deployment API
•
Management API
Version 1.1 – Marcus Gelderman, email: [email protected]
35 / 45
Web Service, SOAP och WSDL
Web Service
Begreppet Web Service är definierat av W3C (World Wide Web Consortium) till "a software system designed to
support interoperable machine-to-machine interaction over a network". Web Service som grund innebär att man
publicerar tjänster (tjänsterna är i praktiken motsvarigheten till funktioner i ett proceduriellt programmeringsspråk). Dessa tjänster kan anropas av omkringliggande system men även internt ifrån samma system.
Vanligtvis kan man se Web Service-tjänsterna som ett Webb API.
SOAP
SOAP är ett protokoll för utbyta XML-baserade meddelande över ett nätverk. Vanligtvis är protokollen http eller
http/s de bärande protokollen för informationen, men SOAP-standarden tillåter andra protokoll; exempelvis
SMTP. Tidigare stod SOAP för ”Simple Object Access Protocol” men i och med version 1.2 av standarden så
släppte man den utläsningen av förkortningen eftersom den ansågs missvisande (Vad man förväntar sig att förkortningen SOAP skall stå för nu har inte gått att utröna).
Bland fördelarna med SOAP är att det är plattforms- och språkoberoende och det är ett enkelt protokoll att få
igenom brandväggar och proxie servrar. Nackdelarna anses vara att det är XML-baserat och följaktligen skickas
det mer data, vilket gör att det anses som långsammare än andra protokoll särskilt då stora datamängder skall
utväxlas.
Web Services Description Language (WSDL)
WSDL är ett sätt att beskriva hur en Web Service tjänst skall anropas. Nuvarande version av WSDL-standarden
är nu på 2.0 och en rekommenderad standard ifrån W3C (World Wide Web Consortium) – W3C Recommendation (REC). När man väljer verktyg för att utveckla Web Services skall man vara lite vaksam eftersom en hel del
av verktygen endast genererar WSDL: er som uppfyller 1.1 av standarden. Att nyttja WSDL: er är inget måste
om man vill använda sig av Web Service men man bör komma ihåg att WSDL dokumentet (i praktiken är det en
XML-fil) är samtidigt dokumentationen över hur anrop av Web Service tjänsten skall ske. Rent praktiskt brukar
det bara ytterst fördelaktigt att nyttja WSDL: er både ur Web Service tjänsteleverantörens synkvinkel, då det ofta
innebär ytterst marginellt mer arbete för att få fram en WSDL och ur tjänste konsumentens synvinkel, då det ofta
bara är att mata utvecklingsmiljön med WSDL: en för att få fram kod som kan ansluta till Web Service-tjänsten
automatiskt.
Version 1.1 – Marcus Gelderman, email: [email protected]
36 / 45
XML
Extensible Markup Language (XML) är ett generellt ”markup language”. Ursprunget till XML kommer ifrån Standard Generalized Markup Language (SGML) men XML har designats så att det skall vara lite enklare. XML är i
dag en av de största standarderna för informations utbyte och serialisering av data. I och med XMLs utbreddhet
finns det stöd för XML i de flesta programmeringsspråk, antingen direkt i språket eller via tillägg till programmeringsspråket. XML är en fri öppen standard och dess användning rekommenderas av World Wide Web Consortium (W3C).
Version 1.1 – Marcus Gelderman, email: [email protected]
37 / 45
XML Schema
En XML Schema Defintion (XSD) har vanligtvis filändelsen ”.xsd” och är i praktiken en XML fil. XML Schema är
ett bra sätt att verifiera att en XML-fil innehåller de värden man förväntar sig och följer de syntaktiska regler man
har definierat för sin XML fil och den data som skall utbytas. XML Schema är ett bra och oklanderligt sett att
dokumentera XML-filer på. I de flesta programmeringsspråk finns det möjlighet att validera en XML-fil mot en
XML Schema Defintion. I Java finns mekanismer för att omvandla en XML-fil till en Java böna (se JAXB) enligt
den mall som XML Schema Defintion har definierat.
Användandet av XML Schema är oftast inte så utbrett och tekniken missuppfattas ofta som krånglig och svårhanterad. Rätt använd ger den möjlighet till ett otroligt väldefinierat data utbyte med möjlighet till avancerade
kontroller av data mot ett eget definierat regelverk. Kombinerat med tekniker som JAXB så ger den en otrolig
tidsbesparing. I många fall kan det inte vara försvarbart att inte nyttja fördelarna med XML, XML Schema och
JAXB när man ser hur mycket utvecklingstid man kan spara in.
Version 1.1 – Marcus Gelderman, email: [email protected]
38 / 45
Java Architecture for XML Binding (JAXB)
JAXB erbjuder teknik för att kunna serialisera och deserialisera Java-bönor. JAXB är inget underverk av högteknologi men erbjuder istället en teknik som rätt använd sparar väldigt mycket tid under utvecklingsstadiet av ett
system. Nyttjandet sker i två steg. JAXB kompilatorn skapar java klasser utifrån ett XML Schema. I Steg två använder utvecklaren de skapade klasserna för att omvandla ett XML meddelande eller fil till en Java böna som
ligger i minnet.
Version 1.1 – Marcus Gelderman, email: [email protected]
39 / 45
Spring Framework
Spring är ett open source ramverk för Java Enterprise lösningar. Spring kan användas på många olika sätt och
ger ett bra stöd för att enklare kunna nyttja Hibernate i en webblösning. Som ramverk är Spring ganska enkelt
och det kräver inte att man använder all funktionalitet utan ger utvecklaren möjlighet att set till behoven och sedan välja vilka delar som man nyttja av ramverket. Det som gjort Spring populärt är det extra stöd man får av
ramverket för att bygga webbapplikationer och Spring erbjuder färdiga lösningar på några av de lite kluriga problemen man kan stöta på som Java Enterprise Edition (Java EE) utvecklare.
Några av funktionerna som gör Spring Framework unikt är:
Inversion of Control container
Inversion of control (IoC) bygger på den kända Hollywood-principen ”ring inte oss; vi ringer dig”. I praktiken innebär detta att applikationen blir lite bättre integrerad och man får en högre grad av återanvändning av skapad
kod.
Aspect-orienterad programmering
Aspect-oriented programming (AOP) och aspect-oriented software development (AOSD) är ett försök hjälpa
utvecklaren att separera funktionalitet så mycket som möjligt. I de flesta fall kan man enkelt separera funktionaliteten i paket, klasser eller metoder, men det finns vissa undantag som exempelvis funktionalitet för loggning.
Loggning dyker upp på ett flertal ställen i koden. Ibland utvecklare brukar detta kallas ”cross-cutting concerns”
eftersom kravet på funktionalitet skär igenom paket, klasser och metoder. Aspekt-orienterad programmering är
kortfattat ett försök att även kapsla in sådan funktionalitet.
Data access och Transaction management ramverk
Data access och Transaction management ramverken underlättar för integration av exempelvis Hibernate och
gör att utvecklaren kan nyttja färdiga lösningar på några av de klurigheter som kan uppstå.
Version 1.1 – Marcus Gelderman, email: [email protected]
40 / 45
ESB (Enterprice service bus)
ESB är ett arkitekturbegrepp inom systemutveckling och syftar på någon form av middleware eller integrationslösning. ESB är lösningen för att kunna skicka meddelande mellan olika komponenter i ett system eller mellan
olika system. Tanken är att på samma sätt som bussen i en dator kan välja att skicka en ström med data till
hårddisken, minnet eller till grafikkortet så skall de olika systemkomponenterna gå att nå i ett större system via
ESB:n. Det finns en mängd produkter att välja mellan för att lösa ESB frågan och för att få rätt produkt behöver
den utvärderas mot de system som den skall kopplas emot. Java världen har legat lite efter med bra produkter
för systemintegration och vissa lösningar är lite väl fyrkantiga för att passa i ett större perspektiv. Vanligtvis har
man ju krav på att kunna kommunicera med väldigt varierande system och över väldigt varierande kommunikationsprotokoll så det är av yttersta vikt att man har inventerat behovet innan man bestämmer sig för en produkt.
Om man är intresserad av Java-baserade open source-lösningar så finns det i alla fall två lösningar som man
bör kika på:
xBus (http://xbus.sourceforge.net/)
Apache ServiceMix (http://servicemix.apache.org/)
Vill man ha en ren JMS-lösning så kan man även JBoss Messaging (http://www.jboss.org/jbossmessaging/)
vara ett alternativ (se JMS).
Version 1.1 – Marcus Gelderman, email: [email protected]
41 / 45
Java Message Service (JMS)
Java Message Service (JMS) API är ett ”Java Message Oriented Middleware” (MOM) API för att skicka meddelanden mellan två eller fler klienter. JMS är en del av Java EE (Java Platform, Enterprise Edition) och är definierad
i Java Community Process as JSR 914. JMS stödjer två både point-to-point (queuing) mode samt publish and
subscribe mode.
När man väljer att skicka point-to-point så kan det bara finnas en mottagare till meddelandet och man har en
hantering för att se att mottagaren har mottagit meddelandet. Mottagaren av meddelandet behöver inte vara
tillgänglig när meddelandet skall skickas och sändaren behöver inte vara tillgänglig när ett meddelande skall tas
emot. Väljer man skicka med publish and subscribe så kan man ha flera mottagare av ett meddelande. Är man
inte lyssnande när ett meddelande skickas så missar mottagaren det meddelandet (Det finns undantag till och
det går att skapa en prenumeration som åter sänder de meddelande man eventuellt har missat om man inte har
varit ansluten). Det finns ett flertal JMS-leverantörer och det finns en abstraktions mekanism i implementeringen
som gör att man kan återanvända sin kod om man av någon anledning väljer att byta JMS-implementation. Viktigt att notera är att två olika leverantörers JMS-lösningar inte behöver fungera särskilt bra tillsammans och
ibland inte alls; bäst resultat får man om man uteslutande väljer en leverantörs JMS-lösning.
JBoss har en JMS-lösning i sitt system (JBoss Messaging) och Apache har sin Apache ActiveMQ
(http://activemq.apache.org/): Andra kända open source JMS-lösningar är OpenJMS
(http://openjms.sourceforge.net/) och JORAM (http://joram.objectweb.org/).
Om man vill föredrar att betala en licenskostnad för JMS-implementationen så erbjuder i alla applikationsservertillverkare och några fristående företag en JMS-lösning där kanske IBMs Websphere MQ och SonicMQ är de
mest kända produkterna. De mest kända leverantörerna är troligtvis Oracle, IBM, BEA Weblogic, TIBCO samt
SAP AG.
Version 1.1 – Marcus Gelderman, email: [email protected]
42 / 45
JUnit
JUnit
JUnit är ett Java ramverk för enhetstester. JUnit är väldigt enkelt att använda och kräver inte så mycket energi
av utvecklaren för att skriva testerna. I och med att JUnit är så pass lättanvänt som det faktiskt är så bör man
lägga lite mer energi på att fundera ifall de testerna man skrivit är relevanta.
Konventionen säger att ett testcase namn skall avslutas med ”Test” och en metod skall börja med test. Koden
nedan visar hur en bit test kod kan se ut. I detta fallet använder man Java annotation för att markera vad som är
ett testcase
public class HelloWorld
{
@Test public void testMultiplication()
{
// Testing if 3*2=6:
TestCase.assertEquals ("Multiplication", 6, 3*2);
}
}
Version 1.1 – Marcus Gelderman, email: [email protected]
43 / 45
Asynchronous JavaScript And XML (Ajax)
Asynchronous JavaScript And XML – Ajax är samlingsnamnet på en webbteknik där man låter JavaScript-kod
ute hos klienten kommunicera med servern via det vanliga http eller http/s protokollet men skillnaden är att man
dynamiskt uppdaterar vad användaren ser. Den stora fördelen med denna teknik är att webbapplikationen blir
betydligt mer lik en traditionell vanlig applikation eller en fet klient fast man inte kräver någon installation ute hos
klienten. Denna teknik är väldigt vanlig och används på de flesta större webbplatser i någon form. Nackdelarna
med tekniken är att den är lite pillig att få till och att man ställer höga krav på att utvecklingsmiljön är snabb så
man kan snabbt göra ändringar och testa. Utvecklingen bedrivs ofta i snabba ändra, testa, ändra och testa cykler. En annan nackdel är att variationer i implementering av webbläsarna göra att man är tvungen att testa mot
alla de läsare som man bestämt sig skall stödja och kan tvingas göra unika lösningar för vissa av webbläsarna.
En stor fördel är att de nyare mobila plattformarna som exempelvis Apples iPhone har ett bra stöd för JavaScript
i webbläsaren och att en webblösning som fungerar bra mot Apples webbläsare Safari fungerar med få eller
inga modifieringar mot den mobila plattformen. Tidigare har möjligheterna att bygga en bra klientmiljö för mobila
enheter varit väldigt kostsamt och svårt eller rent ut omöjligt.
Version 1.1 – Marcus Gelderman, email: [email protected]
44 / 45
