ICT Architectuur voor de nieuwe Digitale Leer- en Werkomgeving

ICT Architectuur voor de nieuwe Digitale Leer- en Werkomgeving

Betreft

ICT Architectuur voor de nieuwe Digitale Leer- en Werkomgeving

Van

Eelco Laagland

Voor

Commissie ELO advies, MT ITBE en projectleden

Datum

18 oktober 2005

Kenmerk

ITBE 05/10321

______________________________________________________________________________________ 1

______________________________________________________________________________________ 2

Inhoud 1 2 3 4 5

Management samenvatting..................................................................................................... 5 Inleiding................................................................................................................................... 5 ICT Architectuur ...................................................................................................................... 6 Overzicht technische ontwikkelingen e-learning..................................................................... 6 Service Oriented Architecture (SOA)...................................................................................... 8 5.1 Beschrijving .................................................................................................................... 8 5.2 IMS Abstract Framework................................................................................................ 8 5.3 Een voorbeeld .............................................................................................................. 10 5.4 Best-of-breed................................................................................................................ 11 5.5 Beheerslast verminderen ............................................................................................. 11 5.6 Voorbeeld: Studentprofiel............................................................................................. 13 5.7 SOA en Framework...................................................................................................... 14 6 Framework initiatieven .......................................................................................................... 14 6.1 SAKAI........................................................................................................................... 14 6.2 ELF the e-learning Framework..................................................................................... 17 7 Open Source......................................................................................................................... 19 8 Conclusies ............................................................................................................................ 20 8.1 Scenario 1: Klassieke commerciële ELO..................................................................... 20 8.2 Scenario 2: Klassieke Open Source ELO .................................................................... 20 8.3 Scenario 3: SAKAI ....................................................................................................... 20 9 Bronnen................................................................................................................................. 21 10 Bijlage: Voorlopig indicatieve lijst ELO’s............................................................................... 22

______________________________________________________________________________________ 3

______________________________________________________________________________________ 4

1 Management samenvatting In dit rapport wordt een mogelijke ICT Architectuur voor de nieuwe Digitale Leer- en Werkomgeving (DLWO) van de UT geschetst waarmee een toekomstvaste en flexibele voorziening voor geïntegreerde informatievoorziening gerealiseerd kan worden. Na een korte historische schets van de technologische ontwikkelingen van e-learning aan de UT zal het model van Service Oriented Architecture (SOA) toegelicht worden en zullen een tweetal projecten die gebaseerd zijn op dit model geanalyseerd worden. In rapport F zal de bestaande leeromgeving van de UT, TeleTOP, vergeleken worden met de in rapport C (Interoperabiliteit en standaarden in de nieuwe Digitale Leer- en Werkomgeving) en dit rapport beschreven aspecten. Ook mogelijke andere alternatieven zoals Moodle en Blackboard zullen in rapport F beoordeeld worden. De conclusie is dat de UT staat voor en fundamentele keuze tussen de klassieke monolithische ELO’s en de opkomende op separate komponenten gebaseerde e-learning frameworks. Bij een keuze voor een klassieke ELO zijn er twee scenario’s die in aanmerking komen: 1 - Doorgaan met TeleTOP en de gewenste en noodzakelijk wijzigingen in overleg met de leverancier laten aanbrengen, of overgaan naar een andere klassieke ELO. In dit scenario zijn Blackboard/WebCT1 en N@tSchool enkele mogelijke alternatieven 2 - Overgaan naar een open source klassieke ELO. In dit scenario zouden bijvoorbeeld Moodle en Dokeos een mogelijke keuze zijn. Kiest de UT voor een op SOA gebaseerde oplossing dan komt het derde scenario in beeld: 3 - het SAKAI Open Source project, mogelijk in kombinatie met komponenten die in andere projecten ontwikkeld zijn, bijvoorbeeld in het JISC E-Learning Framework. Een eventuele overgang naar SAKAI vereist een robuuste voorbereiding en mogelijk een extra professionaliseringsslag binnen de UT organisatie, met name het ITBE, op het gebied van webservices en Open Source software.

2 Inleiding Het voorliggende rapport D is opgesteld in het kader van het project “ELO Keuzetraject”, dat als doel heeft om de commissie ELO advies van informatie te voorzien om te komen tot haar advies aan het CvB over de toekomstige digitale leer- en werkomgeving van de Universiteit Twente. Rapport D is het vierde rapport in een reeks van zes. Het betreft een advies over de gewenste ICT architectuur van de nieuwe DLWO evenals een beschrijving van een twee internationale projecten die deze gewenste architectuur als uitgangspunt hebben genomen en waar de UT mogelijk bij aan zou kunnen sluiten.

1

In een persbericht d.d. 12-10-2005 is een fusie tussen Blackboard en WebCT aangekondigd.

______________________________________________________________________________________ 5

3 ICT Architectuur Waar hebben we het eigenlijk over als we in dit verband het begrip architectuur gebruiken? Het WTR Adviesrapport voor het SURF-Meerjarenplan 2007-2010 ‘Kiezen en delen’2 definieert architectuur in de context van ICT als: ‘Een informatie -infrastructuur is een permanente, structurele voorziening ten behoeve van gegevensuitwisseling en communicatie3. De informatiearchitectuur is het beeld / de beschrijving daarvan.’ Deze informatiearchitectuur wordt gedragen door een technische infrastructuur die grotendeels is gebaseerd op standaarden en protocollen die hun waarde bewezen hebben (HTTP, TCP/IP). Er ontstaat nu een behoefte om op het niveau van gegevens en applicaties te komen tot de vorming van een informatie -infrastructuur (bron: SURF WTR Adviesrapport). Een belangrijke recente ontwikkeling bij het beschrijven van deze informatie -infrastructuur is het model van Service Oriented Architectures (SOA’s). Hierop zijn de nieuwe generatie e-learning architecturen gebaseerd onder de naam e-learning frameworks. Na een kort historisch overzicht van de technische ontwikkelingen van het met electronische middelen ondersteunde leren aan de UT zullen we in hoofdstuk 5 dieper ingaan op deze op SOA gebaseerde frameworks.

4 Overzicht technische ontwikkelingen e-learning Het gebruik van ICT in het onderwijs is de afgelopen 20 à 30 jaar door vele evoluties gegaan, van de vroege mainframe computers, via de mini’s en de microcomputers in de jaren ’80, de personal computers in de jaren ‘90 naar het zich snel ontwikkelende webbased leren van tegenwoordig. Kort samengevat en op een tijdslijn geplaatst ziet die ontwikkeling er als volgt uit:

Figuur 1: Overzicht belangrijkste technologie e-learning platforms

2 3

http://www.surf.nl/publicaties/index2.php?oid=198 Matthijsse, R., Ontwikkelingsproces als biologisch groeimodel, Computable, 18 december 1998, nr

51, pag 64. ______________________________________________________________________________________ 6

1. Mainframes (tot en met. begin jaren 80). In de jaren 70 werden aan de UT de eerste stappen op het gebied van Computer Assisted Instruction (CAI) leren gezet, toen nog met behulp van o.a. een IBM 360 mainframe en LA36 schrijfmachineterminals. De vakgroep Digitale Techniek (EL) heeft voor de toenmalige THT pionierswerk verricht. Met de opkomst eind jaren ‘70 van beeldschermterminals (VT52 e.d.) kwamen de eerste auteurssystemen op de markt. Control Data was de onbetwiste leider op de markt voor CAI met een eigen grafisch ‘leerstation’ via gehuurde telefoonlijnen verbonden met een centrale Cyber mainframe in Brussel en PLATO (Programmed Logic for Automatic Teaching Operations) als auteursomgeving. DEC zette met DAL (Digital Authoring Language) al snel de aanval in op de marktleider. 2. Mini’s (t.m. midden jaren 80). Aan het eind van de jaren 70 kwamen de minicomputers sterk op: aan de UT waren de PDP-11 en de VAX erg populair, in het HBO werd de PRIME mini veel ingezet. De tooling bestond nog grotendeels uit de in de mainframe periode ontwikkelde software geport naar mini’s, aangevuld met nieuwe ontwikkelingen zoals het aan de UT ontwikkelde TAIGA dat in eerste instantie voor mini’s ontwikkeld werd. De toenmalige ‘Interfacultaire Werkgroep Computer Ondersteund Onderwijs’ heeft destijds in opdracht van het CvB een belangrijke impuls gegeven aan de inzet van ICT t.b.v. het onderwijs aan de UT. 3. Microcomputers (t.m. 1990). Begin jaren 80 kwamen de eerste microcomputers op de markt die al snel in populariteit toenamen. Aan de UT werden al snel de eerste microcomputers aangeschaft: de Victor 9000. Het auteurssysteem TAIGA werd geschikt gemaakt voor de onder MS-DOS en PC-DOS draaiende micro’s. Aansturing van de grafische kaarten werd met behulp van Graphics System eXtension (GSX) verzorgd, een voorloper van MS-Windows. Voor ieder microcomputer moest vaak een eigen versie van de software ontwikkeld worden. 4. Stand-alone Personal Computers (jaren 85-95). Met de komst van de IBM PC in 1984 en de eerste versie van MS-Windows kort daarna (1985) kon software voor het eerst grootschalig toegepast worden. Het Grafische Userinterface was een belangrijke drijfveer voor allerlei nieuwe producten. De UT initieerde in die periode de ontwikkeling van de opvolger van TAIGA, een auteurssysteem dat onder naam Inigo op de markt werd gebracht. Een ander veel gebruikt systeem voor CBT ontwikkeling was MS-Visual Basic, Authorware en Toolbook. Portabiliteit van courseware was een ‘hot item’ op conferenties en de verwachtingen van brede inzet van ICT in het onderwijs waren hoog gespannen. 5. Connected Personal Computers (Webbased). Met de opkomst van het internet in het midden van de jaren ’90 werden PC’s met elkaar verbonden en ontstonden de eerste electronische leeromgevingen, al lag het accent bij het gebruik in het begin voornamelijk op wat in de jaren ervoor als Computer Managed Instruction (CMI) werd aangeduid: de organisatie van en de communicatie rondom het leren. De eigenlijke overdracht van kennis vond nog voornamelijk via klassiek onderwijs plaats. Ook bij deze ontwikkeling heeft de UT er destijds voor gekozen voorop te blijven lopen met de toepassing van ICT in het onderwijs. Bij de afdeling Toegepaste Onderwijskunde werd in de tweede helft van de jaren ’90 de electronische leeromgeving TeleTOP ontwikkeld, die in 1998 instellingsbreed op de UT is geïmplementeerd. TeleTOP is gebaseerd op een IBM Lotus Domino platform. In een poging om de uitwisselbaarheid en toepasbaarheid van het ontwikkelde materiaal en gereedschap te vergroten is een behoefte aan specificaties en standaarden ontstaan. De hoop en verwachting van deze specificaties is dat ze de overdraagbaarheid en herbruikbaarheid van content tussen bestaande platforms en naar nieuwe toekomstige platforms zullen vergroten. Om de verschillende specificatie en standaarden in een logisch samenhangend verband te kunnen plaatsen worden rond 2000 de eerste stappen gezet in de richting van de huidige ontwikkeling:

______________________________________________________________________________________ 7

6. E-learning frameworks. De inmiddels als ‘klassiek’ bestempelde electronische leeromgeving die rond eeuwwisseling zijn hoogtepunt kende wordt meer en meer gezien als een beperkende factor bij de integratie met administratieve systemen4. Ook worden de beperkte mogelijkheden om op een flexibele wijze diverse onderwijsscenario’s te implementeren (de juiste ‘blend’) als te rigide ervaren. De afhankelijkheid (‘vendor lockin’) van de ondersteunde didactiek en de roadmap van een enkele leverancier (met name van de huidige marktleiders in de hoger onderwijs markt Blackboard/WebCT) is een bron van frustratie voor veel instellingen. In het volgende hoofdstuk worden een tweetal trends besproken die als mogelijke oplossingsrichting worden gezien: Service Oriented Architecture, Open Source Software.

5 Service Oriented Architecture (SOA) 5.1 Beschrijving Het model van Service Oriented Architectures gaat uit van het beschrijven van een informatie – infrastructuur als een verzameling van autonome services die met elkaar communiceren. Deze communicatie kan een eenvoudige producent-afnemer relatie zijn tussen twee services of een meer complexe samenwerking tussen meerdere services. Een service is een functionele eenheid (een programma) die duidelijk gedefinieerd is in termen van datamodellen, interfaces en dynamisch gedrag en kan gezien worden als een bouwsteen waarmee grotere functionele eenheden (applicaties) kunnen worden samengesteld.

5.2 IMS Abstract Framework Het IMS5 heeft met het Abstract Framework een gelaagd model van deze architectuur ontwikkeld voor het e-learning domain waarmee dit principe verduidelijkt kan worden, zie figuur 1:

4 5

Zie: Projectdefinitie ELO Groei- en Verandermanagement, Digitale Universiteit. IMS Global Learning Consortium (http://www.imsproject.org/)

______________________________________________________________________________________ 8

Figuur 2: IMS Abstract Framework: gebaseerd op een diagram van IMS AF Het IMS Abstract Framework onderscheid de volgende 4 lagen: 1. De Application laag De Application laag bestaat uit een verzameling educatieve toepassingen ten behoeve van de gebruiker. Voorbeelden van educatieve toepassingen op dit niveau zijn een portfolio applicatie, een content management applicatie, een bibliotheek systeem, een assesment systeem. Een ELO kan een aantal van deze applicaties bevatten, maar applicaties kunnen ook zelfstandig buiten de ELO bestaan. Op het niveau van de Application laag wordt het gebruikersinterface gerealiseerd. Een applicatie kan opgebouwd zijn uit functionaliteit die geleverd wordt door een of meerdere services uit de onderliggende lagen, waarbij de koppeling (interface) zoveel mogelijk via gestandaardiseerde protocollen plaats vindt zodat services gewijzigd of vervangen kunnen worden zonder dat de afnemende applicaties hiervan hinder ondervinden. 2. De Application Services laag Een verzameling services die de gewenste e-learning functionaliteit leveren ten behoeve van de appplicaties. Deze laag wordt in sommige architectuur modellen (OKI6 b.v.) ook wel de Educational Services laag genoemd. Een application service kan op zijn beurt weer gebruik maken van de diensten die verleend door een of meerdere common services. Application services kunnen waar nodig ook rechtstreeks gebruik maken van de communicatiemogelijkheden die door de Infrastructuurlaag worden geboden. Voorbeelden van Application Services zijn Activity management, Sequencing, Competency Management, Tracking en Tracing.

6

OKI: Open Knowledge Initiative: http://www.okiproject.org

______________________________________________________________________________________ 9

3. De Common Services laag Een verzameling services die niet specifiek is voor het educatieve domein en die ten dienste staan van de application services. Common services kunnen ook weer gebruik maken van de diensten die door andere Common Services worden aangeboden. Voorbeelden van Common Services zijn AV Conferencing, Calender, Chat, Mail. 4. De (technische) Infrastructuur laag Deze laag verzorgt de communicatie en de toegang tot de technische infrastructuur voor de Application en Common Services. De toegang tot een bepaalde service verloopt via een zogenaamd Service Access Point (SAP). Iedere service heeft één enkel Service Access Point. De verzameling services wordt aangeboden (geïmplementeerd) door een verzameling afzonderlijke componenten waarbij een component in een enkele of meerdere services kan voorzien en de bijbehorende SAPs kan leveren. Het IMS werkt nauw samen met OKI zodat de modellen op elkaar afgestemd zijn en de IMS SAP’s overeenkomen met de door OKI ontwikkelde Open Service Interface Descriptions (OSID’s).

5.3 Een voorbeeld Om een en ander te verduidelijken kunnen we misschien een voorbeeld dichter bij huis nemen, een audiosysteem. De klassieke monolithische ELO’s zijn het best te vergelijken met een zogenaamd minisetje waarbij alle gewenste functies (services) geïntegreerd in een systeem aangeboden worden. De enige flexibiliteit die soms aangeboden wordt zijn de losse luidsprekers die eventueel vervangen kunnen worden door andere exemplaren.

All-in-one oplossing

Componenten model

Figuur 3: SOA in de audiowereld De Service Oriented Architecture kan vergeleken worden met het samenstellen van een audiosysteem uit losse komponenten (services). Hierbij kan de gebruiker zelf op grond van de gewenste specificatie een aantal componenten kiezen waarmee de gewenste functionaliteit geleverd wordt. Er kan voor iedere functie een aparte komponent gekozen worden, maar ook kan er voor gekozen worden dat enkele services geleverd worden door een enkele component. Zo kan bijvoorbeeld de service ‘Radio’ geleverd worden door twee aparte componenten ‘Tuner’ en ‘Versterker’ maar er zijn ook komponenten verkrijgbaar waarbij beide services geïntegreerd geleverd worden (‘Receivers’). Het voordeel van deze op losse componenten gebaseerde ‘architectuur’ is dat er een precies op de behoefte afgestemde verzameling services, oftewel ‘applicatie’ kan worden gerealiseerd. Losse komponenten (b.v. de CD speler) kunnen vervangen worden zonder dat de andere services hiervan hinder ondervinden, en er is een geleidelijk groeipad mogelijk voor uitbreiding met nieuwe services als de noodzaak hiervoor ontstaat, bijvoorbeeld vervanging van de CD speler door een DVD speler of de vervanging van de 2 kanaals versterker door een 5 of meerkanaals surround versie. Cruciaal voor deze architectuur is

______________________________________________________________________________________ 10

natuurlijk een verzameling open standaarden voor de onderlinge koppelingen (Service Access Points) en de signalen.

5.4 Best-of-breed Uit de voorgaande vergelijking met de audiowereld is al duidelijk wat een belangrijk voordeel van deze op losse interoperabele komponenten gebaseerde architectuur is: er kan gezocht worden naar een verzameling componenten die zo goed mogelijk aansluit bij de instellings behoeften en die in hun klasse de zogenaamde ‘best-of-breed’ vertegenwoordigen. Hierbij zal ook niet altijd een 100% match gerealiseerd kunnen worden, maar er is in ieder geval een keuzemogelijkheid en als uiterste oplossing het zelf of samen met partners (DU, 3TU) ontwikkelen van de gewenste component. Omdat veel componenten in de vorm van Open Source software beschikbaar zijn kunnen ook aanpassingen aan bestaande componenten uitgevoerd worden. Er kan voorzichtig gekonkludeeerd worden dat ook bij klassieke ELO’s waarschijnlijk de 80/20 regel van toepassing is: bij ELO’s als Blackboard en WebCT en ook TeleTOP werd en wordt in het algemeen een groot deel van de ontwikkelinspanning van de leverancier gestoken in de 20 % van de functionaliteit die door 80% van de gebruikers benut wordt. De kwaliteit van resterende 80% van de functies laat soms te wensen over. Dit is voor commerciële leveranciers een begrijpelijk model, maar levert niet altijd het gereedschap voor innovatieve inzet van ICT in het onderwijs. Een voorbeeld is de assesment voorziening in Blackboard en TeleTOP. In beide gevallen voldoet de ‘standaard’ voorziening niet voor serieuze inzet bij het afnemen van assesments, en is er ook geen of weinig ondersteuning voor e-learning specificaties als Question & Test Interoperability (zie rapport C). De gebruikende instelling neemt dan vervolgens zijn toevlucht tot een separaat systeem (bijvoorbeeld Question Mark Perception of TestVision) dat in sommige gevallen moeizaam of niet voldoende te integreren is met de ELO. Bij een SOA model kan uit meerdere Assesment komponenten die voldoen aan de OKI Assessment OSID gekozen worden. De verwachting is dat niet alleen Open Source oplossingen maar ook commerciële komponenten beschikbaar zullen komen7. Met name in de beginperiode zullen deze komponenten niet niet helemaal ‘plug and play’ zijn, maar nog een zekere integratieinspanning vereisen, maar naarmate de standaarden zich ontwikkelen en volwassener worden zal het vervangen van komponenten eenvoudiger worden.

5.5

Beheerslast verminderen

SOA’s hebben een aantal voordelen. Naast het voordeel dat we binnen zo’n architectuur veel gemakkelijker voor best-of-breed kunnen kiezen, kan een SOA ook zorgen voor een vermindering van de beheerslast. Functionaliteit die gemeenschappelijk is voor verschillende systemen (b.v. ELO, Portaal, SIS, bibliotheeksystemen) maar die nu in ieder van de systemen afzonderlijk geïmplementeerd is, kan in een SOA als service ter beschikking gesteld worden aan de verschillende systemen. De systemen worden daarmee minder complex en vergen daarmee minder beheerslast8. Zo zullen alle systemen waarschijnlijk een Authenticatie en Authorizatie voorziening nodig hebben en zullen de ELO (VLE, Virtual Learning Environment) en het biliotheeksysteem functies op het gebied van Content Management, Discovery en Packaging gemeenschappelijk hebben. Figuur 3 geeft de bestaande situatie aan de UT weer. De VLE (TeleTOP), de Digitale Biliotheek en de Student Informatie Systemen (TAST/TOST/VIST) zijn ontworpen als op zichzelf staande applicaties en hebben dientengevolge overlappende functionaliteit.

7 8

Zie Alt-I-Lab 2005 Demonstrators: http://www.cetis.ac.uk/content2/20050901184010 Bron: The case for a technical framework to support MLEs and e-Learning

______________________________________________________________________________________ 11

Figuur 4: Dubbele functies in verschillende systemen Door deze geïdentificeerde gemeenschappelijke functies uit de separate systemen te halen en vervolgens als service aan te bieden in een SOA wordt een eenvoudiger en beter te onderhouden totaalomgeving gerealiseerd. De oorspronkelijke systemen zijn eenvoudiger geworden en kunnen zich richten op het leveren van kwalitatief hoogwaardige specifieke functionaliteit.

______________________________________________________________________________________ 12

Figuur 5: Overlappende functies uit de verschillende systemen gehaald en als generieke functie beschikbaar Overigens is het technisch mogelijk dat de services (in het onderste gedeelte van figuur 4) geleverd worden door een van de oorspronkelijke systemen door dit systeem te voorzien van het benodigde SOA interface.

5.6 Voorbeeld: Studentprofiel Een van de wensen die door studenten is geuit in de enquête (zie rapport B) is het betere gebruik van studentprofielen bij het presenteren van informatie. Op dit moment wordt door het Studenten portaal (MyCampus) al eenmalige login gerealiseerd voor de verschillende deelapplicaties, maar er zou bijvoorbeeld gebruik gemaakt kunnen worden van door de student ingevoerde accessiblity informatie. In het meest ideale scenario hoeft de student deze voorkeuren slechts eenmaal in te voeren en kunnen alle deelsystemen hiervan gebruik maken bij de presentatie. Zo is het door SURF ontwikkelde student inschrijfsysteem Studielink voorzien van de mogelijkheid om niet alleen de standaard gegevens te vragen (adres/woonplaats/mail e.d.), maar kan er voorzien worden in het invoeren van accessibility voorkeuren. Deze informatie kan in de vorm van een IMS

______________________________________________________________________________________ 13

Learner Information Profile record (met IMS Accessiblity uitbreiding) doorgegeven worden aan de afnemende instellingssystemen. Studielink is hiervoor uitgebreid met een generieke adaptor9.

5.7

SOA en Framework

In rapport C is ingegaan op het belang van open specificaties en standaarden voor het realiseren van dit soort architecturen. Niet alleen voor de interoperabiliteit binnen het e-learning domein, maar ook voor interoperabiliteit met bibliotheek en Student Informatie Systemen zoals aangegeven in het voorgaande voorbeeld. Niet alleen over de toegepaste datamodellen maar ook over de manier van koppeling door bijvoorbeeld web services zullen eenduidige afspraken moeten worden gemaakt. Dit geheel van afspraken wordt vaak aangeduid als een framework. In het volgende hoofdstuk zullen de twee meest prominente op SOA’s gebaseerde frameworks, te weten SAKAI en JISC-ELF, beschreven worden.

6 Framework initiatieven In de definitiefase van het (nog lopende) DU project ELO Groei- en Verandermanagement zijn vijftien internationale en nationale framework-initiatieven geïdentificeerd, die vervolgens geanalyseerd zijn op onder andere component gebaseerde bandering, relevantie voor het Nederlandse HO en beschikbaarheid van informatie over de toekomststrategie Aan het einde van de definitiefase is besloten om bij een tweetal veelbelovende concrete framework-initiatieven aan te sluiten, te weten SAKAI en ELF. De volgende beschrijvingen van SAKAI en ELF zijn (verkort) overgenomen uit de definitiestudie van het DU project ELO Groei- en Verandermanagement.

6.1 SAKAI 1. kerndoel v.h. initiatief, en korte schets

Wat is Sakai? Sakai is een initiatief van een aantal gerenommeerde Amerikaanse universiteiten om samen een virtuele leeromgeving op basis van ‘open source’ software te bouwen. Sakai is een project, formeel wordt het eind 2005 afgesloten. De initiatiefnemers beschouwen Sakai als een succes als er uiteindelijk een open source virtuele leeromgeving is gebouwd die minstens even goed is als de commerciële top (Blackboard, WebCT e.d.) én als er een blijvende gemeenschap van ontwikkelaars (‘community’) is gevestigd die de verdere ontwikkeling draagt. Waarom Sakai? De functionaliteit van de gevestigde elektronische leeromgevingen (ELO’s) begint hier en daar te knellen. Ze zijn erg gericht op ‘klik en lees’ en veel minder op bijvoorbeeld actief samenwerken. De grote ELO’s krijgen ook monolithische trekken: ze zijn niet voldoende uitbreidbaar en evenmin kunnen ze makkelijk worden ingepast in een bredere set van onderwijskundige toepassingen. Uitbreiden kan vaak alleen door méér modules van dezelfde fabrikant te kopen. En daarbij lopen ondertussen de licentiekosten gestaag op. Daarbij komt: het gaat om onderwijs, één van de kernactiviteiten van universiteiten, dus alle relevante kennis is in huis. En er zijn inmiddels voldoende technische standaarden ontwikkeld om een dergelijke onderneming gemeenschappelijk aan te kunnen pakken zonder te

9

http://www.surf.nl/download/20041112HandreikingSIS-VCH.pdf

______________________________________________________________________________________ 14

vervallen in een ‘richtingenstrijd’. De initiatiefnemers van Sakai zagen dat de tijd rijp was om het zelf te proberen, daarbij fors gesteund door enkele Amerikaanse innovatiefondsen. Wat is er nieuw en uniek aan Sakai? Sakai is pragmatisch. Bij voorkeur worden open standaarden gehanteerd, maar waar dat (nog) niet kan ontwikkelt men, in onderling overleg, zelf iets. Snelheid is immers belangrijk, het project loopt officieel maar tot eind 2005. Sakai biedt ontwikkelaars een raamwerk waarbinnen applicaties (‘tools’ in Sakai-jargon) kunnen beschikken over allerlei generieke functionaliteiten, zoals authenticatie of documentbeheer. Sakai is niet alleen gericht op cursussen en studenten, maar nadrukkelijk ook op instrumenten voor samenwerking, voor onderzoekers, voor onderwijsadministraties, voor on-line bibliotheken e.d. Sakai is volgens de initiatiefnemers het meest ambitieuze project op het gebied van ‘community source software’ tot nu toe. En ondertussen heeft men al geconstateerd dat er op deze manier ook functies kunnen worden ontwikkeld die door commerciële aanbieders niet gebouwd zouden worden, zoals bijvoorbeeld im- of exporttools. 2. belangrijkste concepten

Het Sakai model bestaat uit een aantal belangrijke elementen: Het Sakai raamwerk bestaat uit drie elementen, ‘view’, ‘tool’ en ‘service’ (model/view/controller model). Abstract Sakai environment (service) De architectuur van het Sakai-project is geheel gebaseerd op J2EE (Java 2 platform, Enterprise Edition). De kerngroep van ontwikkelaars is verantwoordelijk voor het ‘framework’ waarin de toepassingen (programma’s voor eindgebruikers, hier ‘tools’ genoemd) draaien. Het raamwerk zorgt met andere woorden voor de koppeling van tools met services aan de ene kant en met de presentatie- en aggregatielaag (portal) aan de andere kant.De architectuur kent een ‘Tool Portability Profile’ (TPP); een set regels waaraan een programma moet voldoen om ‘in’ de Sakai-omgeving te kunnen worden geplaatst en gebruikt. Programma’s die zich houden aan de TPP zijn in principe direct inzetbaar en, los van de geboden functionaliteit, uitwisselbaar. De services zijn gebaseerd ‘open service interface definitions’ (OSID’s) van OKI, het Open Knowledge Initiative. Sakai Technology Portability Profile (tool) Het TPP beschrijft de eigenschappen waaraan een toepassing, (‘tool’), moet voldoen om gegevens te kunnen uitwisselen met enerzijds de client-, en anderzijds de systeemkant. Die uitwisseling is gebaseerd op gestandaardiseerde koppelvlakken (interfaces). Hiertoe wordt waar mogelijk gebruik gemaakt van open standaarden en breed geaccepteerde interfaces. Sakai Style Guide (view) De style guide beschrijft de mogelijkheden tot het aanpassen van UI van tools en de algemene Sakai omgeving. Hiermee wordt de eenheid van presentatie en user interface bewaakt.

______________________________________________________________________________________ 15

3. betrokken partijen/partners en relaties

De organisatie van Sakai Het Sakai project werkt op basis van samenwerking en consensus. Het gebruik van de Sakai software staat iedereen vrij. Instituten die willen bijdragen en/of meebeslissen kunnen deelnemen aan het Sakai Educational Partner Program (SEPP). Dat is niet gratis (het kost 10 K$ per jaar, of 3 K$ voor kleine organisaties), maar is wel een goede basis voor een stabiele en serieuze ontwikkelgemeenschap Naast deze SEPP organisatie onderhoudt SAKAI nauwe relaties met o.a. Open Knowledge Initiatief (MIT), IMS, ADL Behalve SEPP leden (onderwijsinstellingen) kent Sakai ook “commercial affilliates”.(SCA) Dit zijn o.a R-Smart, Harvest Road, Sun, Unisys, Ostrakon & IBM

4. conceptueel of implementatiegericht

Implementatie gericht, Het Sakaiproject levert een “out of the box”bruikbare ELO. Deze ELO is door instellingen zelf te configureren en aan te passen. Naast de SAKAI core (ELO) leveren de diverse SEPP partners diverse tools die nieuwe functionaliteiten toevoegen, enkele voorbeelden zijn : • Twinpeaks, integratie met bibliotheek (repository) systemen • Melete; een course / syllabus builder Deze tools zijn gebaseerd op het TPP model De eerste versie van de ‘Sakai suite’ verscheen eind 2004. Dat was een samenraapsel van allerlei producten van deelnemende partners. In maart 2005 is versie 1.5 verschenen die meer ‘tools’ en meer samenhang levert. In juni 2005 verscheen versie 2.0 die alle trekken van een werkelijk geïntegreerde (maar nog altijd modulaire) ‘suite’ van producten moet opleveren. In versie 2 zijn veel van de bestaande ‘best of breed’ producten opnieuw gebouwd om te voldoen aan de technische vereisten van het Sakai raamwerk.

5. status

Het is de bedoeling om eind 2005 de ‘definitieve’ release, 3.0, uit te brengen waarin een grotere samenhang tussen de diverse onderdelen uit de Sakai Suite bereikt moet zijn. Het Sakai-project is dan formeel ten einde. Over de ‘post-project’ periode wordt nog stevig nagedacht.

6. oordeel over relevantie, toepasbaarheid NL, stabiliteit, etc.

Duidelijk is dat het project zoals het oorspronkelijk is bedacht wellicht met aanvang van 2006 over is, maar dat het Sakai initiatief in de vorm van een community die werkt aan een ‘next generation’ virtuele leeromgeving dan allerminst zal hebben opgehouden te bestaan. Sakai is alleen al door de indrukwekkende lijst van partners relevant om te volgen. Het is in het hoger onderwijs in de VS een breed gedragen en omarmd initiatief. De laatste 12 maanden komen er steeds meer partners van buiten de VS bij. Dit geeft aan dat ook buiten VS Sakai als een belangrijke ontwikkeling wordt gezien. De aantrekkelijkheid van Sakai is de visie dat het in gemeenschappelijkheid ontwikkelen van een e-learning omgeving een enorm potentieel aan “resources”aanboort en het feit dat het HO een directe invloed heeft op de richting en kwaliteit van de diverse producten die uit Sakai project voortkomen. Sakai 2.0 is de eerste serieuze release en in de VS zullen diverse universiteiten dit najaar van start met Sakai als ELO, bv Indiana university met 100.00 studenten. Dit geeft aan dat men vertrouwen heeft in het product, De Sakai core is zonder meer bruikbaar in een Nederlandse onderwijsomgeving. Sakai biedt mogelijkheden voor lokalisatie en internationalisering van de UI.

______________________________________________________________________________________ 16

7. Links

•

• •

6.2

De hoofd website van het SAKAI project http://www.sakaiproject.org/ Op deze website is ook de open source download te vinden. SAKAI knowledge base (algemene informatie) https://www.indiana.edu/%7Esakaikb/ Sakaipedia, The Sakai Encyclopedia http://bugs.sakaiproject.org/confluence/display/ENC/Home

ELF the e-learning Framework

Het doel is het ontwikkelen van een gezamenlijke aanpak m.b.t. Service 1. kerndoel v.h. initiatief, en korte Oriented Architectures voor het onderwijs. schets ELF probeert een alternatief te bieden voor zogenoemde monolithische e-learning systemen door een Framework te ontwikkelen, bestaande uit een - set van services - een toolkit om deze services aan elkaar en aan andere applicaties te koppelen - instructies voor gebruik ELF levert zelf geen architectuur, maar is gericht op de ontwikkeling van een gezamenlijk gedefinieerde en geaccepteerde verzameling (Framework) van functionaliteiten, gebaseerd op het concept van Web services. Organisaties kunnen hiermee vervolgens zelf hun architectuur definiëren en op hun netwerk instantiëren. Dit wordt tamelijk breed opgevat: het gaat hierbij om services ter ondersteuning van e-learning applicaties, portals en ‘andere user agents’. Het doel is niet om een blauwdruk te ontwikkelen voor een open-source VLE (in tegenstelling tot Sakai), maar om de integratie te faciliteren van commerciële, ‘home grown’ en open source componenten en applicaties. Dit moet mogelijk worden door uit te gaan van gezamenlijke service definities, data modellen en protocollen.

2. belangrijkste concepten

ELF is onderdeel van het breder JISC e-learning Programme. Het elearning Programme maakt deel uit van een nog breder programma waarbinnen ook frameworks voor andere domeinen worden ontwikkeld, bijv. e-research. Bij bestudering van ELF documenten komen we een veelheid van concepten tegen, echter zonder dat deze eenduidig worden gedefinieerd, laat staan ‘voorgeschreven’ binnen het framework. Het gaat onder andere om de volgende: learning domain services, common services, Web services, networked services, user agents, SOA, Open standaarden, Open Source. Het ELF kent een drietal lagen, bestaande uit: - common services, oftewel functies die gemeenschappelijk zijn voor een veelheid

______________________________________________________________________________________ 17

-

-

3. betrokken partijen/partners en relaties 4. conceptueel of implementatiegericht

aan systemen over domeinen (38 geïdentificeerd tot nu toe) learning domain services10, die specifiek zijn voor het e-learning domein (17 geïdentificeerd tot nu toe) user agents de toplaag, die het interface voor de gebruiker verzorgen (8 geïdentificeerd tot nu toe)

Deze services en user agents zijn echter binnen het Framework zeer summier gedefinieerd d.m.v. van een label en een een-regelige beschrijving. Ook is er niets over de onderlinge relaties afgesproken. 1. JISC (Joint Information Services Committee, UK) 2. DEST (Department of Education, Science and Training, Australia) 3. LSAL (Carnegie Mellon Learning Services Architecture Lab, USA) 4. anderen ELF wordt expliciet aangeduid als een technische architectuur. Wat dit echter impliceert blijft echter vrij onduidelijk: zo wordt er op het niveau van het framework vrijwel niet naar technologie-standaarden verwezen (hoewel dat in de onderliggende projecten waarschijnlijk wel wordt gedaan). Verder zijn de common services en learning domain services op het niveau van het framework (nog?) niet duidelijk gedefinieerd (enkel gelabeld). Het beeld dat bij ELF naar voren komt is dan ook niet zozeer dat van een framework, maar eerder een community die zich rondom leertechnologie-standaarden verzameld heeft en daar nu handen en voeten aan probeert te geven. De manier van werken is erg bottom-up, waarbij het Framework eerder als ‘logo’ dient waarachter een veelheid van activiteiten plaatsvindt, dan als een structurerend mechanisme.

5. status

Dit heeft wel tot gevolg dat er binnen de projecten pragmatisch en implementatiegericht gewerkt kan worden, waarbij goede producten in volgende projecten meegenomen worden, en slechte afvallen. Er is voorzien dat het ELF Framework constant in ontwikkeling zal blijven, waarbij wel een verschuiving in type activiteiten en op te leveren producten (services) is voorzien. Op het moment (beginsituatie) worden er vooral services ontwikkeld die bovenop bestaande applicaties draaien, en gebruikers (instellingen) in staat stellen hun e-learning architectuur flexibel in te richten. Later zullen deelfuncties die nu nog in ‘grote’ applicaties zitten als individuele services ontwikkeld worden, die direct in de instellings-architectuur opgenomen kunnen worden. Zo ‘groeit’ het aantal services, en neemt het aantal applicaties over tijd af. Op het moment lopen er zo’n 30 open source ontwikkelprojecten, gefinancierd door JISC, die services of ‘adapters’ voor services implementeren: 4 projecten gericht op 3 user-agents; 16 projecten gericht op 8 domain services; en 9 projecten gericht op 5 common services (onlangs is weer een aantal projecten goedgekeurd). Ook binnen andere (m.n. EU) projecten dient ELF als leidraad. Voor een duidelijk beeld van de huidige status zouden alle projecten beoordeeld moeten worden: dit is in het kader van deze analyse niet

10

Deze worden in een doc van Sarah Holyfield (maart 2004) ‘Application Services’ genoemd

______________________________________________________________________________________ 18

6. oordeel over relevantie, toepasbaarheid NL, stabiliteit, etc.

7. Links

gedaan. Er gebeurt een hoop in de projecten die onder de vlag van ELF worden uitgevoerd, maar de huidige status is door het grote aantal initiatieven en het ontbreken van een duidelijke referentie moeilijk vast te stellen. Wellicht dat bepaalde services op niet al te lange termijn binnen bepaalde projecten beschikbaar komen zodat instellingen ze op kunnen nemen in hun e-learning infrastructuur, maar door het ontbreken van een duidelijke overkoepelende strategie en structuur kunnen instellingen hier moeilijk op anticiperen in hun ELO-beleid. - JISC e-Learning Programme: http://www.jisc.ac.uk/index.cfm?name=programme_elearning - JISC Frameworks and Tools strand: http://www.jisc.ac.uk/index.cfm?name=e-learning_framework - JISC Distributed e-Learning Strand: http://www.jisc.ac.uk/programme_edistributed.html - The E-Learning Framework: http://www.elframework.org

7 Open Source Een belangrijk aspekt van besproken frameworks is dat ze ontwikkeld zijn volgens het Open Source model. De voor – en nadelen van dit model is een onderwerp dat buiten het bestek van dit rapport valt, maar dat wellicht van invloed kan zijn op de beoordeling. Financiële voordelen doordat Open Source software gratis te verkrijgen is worden vaak teniet gedaan door noodzakelijke investeringen in de ontwikkel- en ondersteuningssfeer (ook professionalisering) om functionele en intergratiewensen.waarin nog niet is voorzien door standaarden te realiseren. Het meest gehoorde argument voor deelname aan Open Source programma’s is ‘Control Of Destiny’. De Europese Unie benadrukt nadrukkelijk in het Zesde Research Framework Plan dat Open Source ontwikkelingen en standaarden voor platforms, middleware en services een strategisch uitgangspunt is11.

11

Bron: E-learning trends 2004, Digitale Universiteit.

______________________________________________________________________________________ 19

8 Conclusies Op moment van schrijven van deze nota (oktober 2005) is duidelijk dat we ons in een overgangsgebied bevinden tussen de klassieke monolitische ELO’s en de opkomende op separate komponenten gebaseerde e-learning frameworks. In dit project zal dus met name bepaald moeten worden hoe het ambitieniveau van onze instelling zich vertaalt in een keuze tussen deze technologieën en in de tweede plaats wat, gegeven een keuze voor een technologie, daar de beste instrumentatie voor is.

8.1

Scenario 1: Klassieke commerciële ELO

Zijn onze onderwijskundige ambities en wensen in te vullen met een klassieke ELO, dan is aan de orde of we dat nog een aantal jaren met TeleTOP kunnen doen of dat er mogelijk aanleiding is om te overwegen over te stappen naar een alternatieve ELO: Blackboard/WebCT, N@tSchool zijn mogelijke kandidaten die gezien hun verspreiding binnen het Nederlands HO voor de hand liggen. Zie bijlage 1 voor een uitgebreidere lijst van kandidaten.

8.2

Scenario 2: Klassieke Open Source ELO

Willen we een klassieke ELO maar meer invloed op de ontwikkeling van functionaliteit dan kunnen ook open source alternatieven worden overwogen (Moodle, Dokeos). Zie bijlage 1 voor een uitgebreidere lijst van kandidaten.

8.3

Scenario 3: SAKAI

Kiezen we ervoor een nieuwe technologie in huis te halen, ook omdat dat noodzakelijk is vanwege onze onderwijskundige ambities, dan zal beoordeeld moeten worden welk framework het beste past bij de doelstellingen en de infrastructuur van de UT. JISC en SAKAI zijn hier de belangrijkste spelers. SAKAI lijkt hier de beste papieren te hebben, maar er zijn nog wel risico’s verbonden aan de samenwerkingsvorm vanaf 1 januari 2006. Onderzocht zal moeten worden of de versie van SAKAI die eind 2005 opgeleverd wordt voldoende ondersteuning biedt voor de gewenste functionaliteit zoals beschreven in rapport E. Is deze versie concurrerend met de bestaande top en de wijze waarop de ontwikkelcommunity georganiseerd zijn kritische vragen die op dat moment spelen. Ontbrekende componenten zouden bijvoorbeeld gezocht kunnen worden in projecten van het JISC E-Learning Framework maar vereisen dan wel een integratieinspanning (‘Pick and Match’) om ze geschikt te maken voor het SAKAI Framework. Ook het invoeren en ondersteunen van SAKAI zelf en de integratie met de UT ICT infrastructuur vereist een substantiële inspanning van het ITBE op het gebied van webservices en Open Source software. Om deze redenen wordt geadviseerd om een overstap naar SAKAI geleidelijk en getrapt uit te voeren en TeleTOP nog een jaar of twee ter beschikking te houden. In de komende periode kunnen dan ondertussen experimenten en pilots uitgevoerd worden met frameworks en webservices om zo op het juiste moment in te stappen. Wellicht dat de 3TU samenwerking voor extra slagkracht in dit scenario kan zorgen.

______________________________________________________________________________________ 20

9 Bronnen Portier, S.J, & Peters, E.M.A. (2005a). Verslag van een webenquête naar wenselijke veranderingen in het UT onderwijs: Volstaan de huidige ICT voorzieningen? ITBE DOC 05-02, Universiteit Twente. Portier, S.J., & Koopal W.Y. (2005). Scenario’s voor de toekomstige UT: Rapport A . ITBE DOC 05-xx, Universiteit Twente. Portier, S.J., Peters E.M.A, Pasman, J. & ten Tusscher, B. (2005). Gebruik van huidige ICT voorzieningen in het onderwijs van de UT: Rapport B . ITBE DOC 05-xx, Universiteit Twente. Geloven, & M. van, & Koper, R & Veen, J. van der (juni 2004). E-learning trends 2004, Digitale Universiteit. Wetenschappelijk Technische Raad, (18 aug 2005). Kiezen en delen. Advies voor het SURF Meerjarenplan 2007-2010. Stichting SURF. Benneker, F., & Giesbers B., & Gorissen P., & Hermans H., & Kluijfhout E., & Koopal W., & Laagland E., & Rossen J. (27 aug 2005). Projectdefinitie ELO Groei- en Verandermanagment, Digitale Universiteit.

______________________________________________________________________________________ 21

10 Bijlage: Voorlopig indicatieve lijst ELO’s Commerciële ELO’s (willekeurige volgorde): TeleTOP Blackboard N@tSchool WebCT Lotus Learning Space Fronter It’s Learning Docent Click2Learn Saba SCT Lumunis ForceTen The Learning Manager Oracle iLearning Open Source ELO’s Dokeos SAKAI Claroline Moodle Atutor DotLRN Claroline

______________________________________________________________________________________ 22