De techniek van Sakai Campus Blend using Sakai

De techniek van Sakai Campus Blend using Sakai

Betreft

Rapport B: Techniek

Van

Eelco Laagland en Dennis Vierkant

Voor

Opdrachtgever (Sir Bakx)

E

De techniek van Sakai Campus Blend using Sakai

Rapport B Kenmerk : ITBE 07/10137 Datum : 25 juni 2007

Licentie De Creative Commons Naamsvermelding-Niet-commercieel 2.5 Nederland Licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by-nc/2.5/nl/ of stuur een brief naar Creative Commons, 559 Nathan Abbott Way, Stanford, Californië 94305, VS om deze licentie te bekijken.

Inhoudsopgave Samenvatting (Nederlands) ........................................................................................................ 3 Summary (English) ...................................................................................................................... 4 1. 1.1. 1.2.

Inleiding ........................................................................................................................... 5 Integratie, ook instellingsoverstijgend .............................................................................. 5 Nadruk op integratie via architectuur................................................................................ 6

2. 2.1. 2.2.

Inventarisatie Sakai web services................................................................................. 7 Sakai is SOA by design .................................................................................................... 7 Overzicht van de Sakai architektuur................................................................................. 8

3. 3.1. 3.2. 3.3.

Sakai en VIST integreren ............................................................................................. 12 Applicatie Service op VIST ............................................................................................. 12 Open Standaarden en specificaties: XCRI..................................................................... 13 Integreerbaar: Sakai en VIST voorzien van externe application services...................... 13

4. 4.1. 4.2. 4.3. 4.4.

Beschrijving demoapplicatie....................................................................................... 14 Het businessproces ........................................................................................................ 14 Demoapplicatie in Archimate lagen ................................................................................ 15 Demoapplicatie in Archimate lagen aangevuld met SOA ESB ...................................... 15 Integratie onder architectuur........................................................................................... 16

5. 5.1. 5.2. 5.3.

Ondersteuning open standaarden .............................................................................. 18 Visie ................................................................................................................................ 18 Ondersteuning algemene specificaties .......................................................................... 18 Ondersteuning elearning specificaties ........................................................................... 19

6. 6.1. 6.2. 6.3.

Ervaringen met Sakai ................................................................................................... 20 Sakai in gebruik op de UT .............................................................................................. 20 Ontwikkelen van nieuwe functionaliteit in Sakai............................................................. 21 Open Source en Sakai ................................................................................................... 21

7.

Bronnen ......................................................................................................................... 23

Bijlage 1: SCORM trial............................................................................................................... 24 Bijlage 2: Wat is Open Source? ............................................................................................... 25 Bijlage 3: Eclipse & Subversion............................................................................................... 26 Bijlage 4: Spring Framework .................................................................................................... 28 Bijlage 5: BPEL Modellering met ActiveBPEL........................................................................ 30

De techniek van Sakai Campus Blend using Sakai: rapport B

Pagina 2 van 30

Samenvatting (Nederlands) Dit rapport is het tweede in een serie van 4 rapporten. Deze rapporten worden uitgebracht in het kader van het project pilotfase Campus Blend using Sakai (CBUS), dat plaatsvond van augustus 2006 tot en met mei 2007. Het doel van dit rapport is verslag te doen van onze ervaringen met de technische aspecten van Sakai. In het bijzonder hebben we aandacht besteed aan de mogelijkheden om Sakai te integreren met andere ICT systemen die op de UT in gebruik zijn. Hierbij is niet alleen onderzoek gedaan naar de theoretische mogelijkheden, maar is ook een demoapplicatie ontwikkeld om deze interoperabiliteit door middel van web services in de praktijk te toetsen. Hiermee wilden we ook inzicht verwerven in de complexiteit van deze integratietechnologie. Er is ook een beeld verkregen van het soort kennis dat we als organisatie in huis zouden moeten hebben om Sakai als zelfstandig systeem, maar ook als bouwsteen van een geïntegreerde informatievoorziening, aan te kunnen bieden in de toekomst. Sakai onderscheidt niet alleen door het open source karakter van veel andere elektronische leeromgevingen. Een belangrijk kenmerk van Sakai is de architectuur van de software. Er is sprake van een heldere, goed doordachte, service georiënteerde componenten architectuur. Deze architectuur maakt het mogelijk dat wereldwijd verspreide groepen softwareontwikkelaars, relatief onafhankelijk van elkaar, aan functionaliteiten van Sakai kunnen werken. De architectuur maakt het verder bijvoorbeeld mogelijk functionaliteit te ontdubbelen. Waar een voorziening elders al beter aanwezig is (assessment bijvoorbeeld in de vorm van Questionmark Perception) kan deze uit Sakai verwijderd worden (in dit geval SAMigo, het Sakai assesment tool). Maar ook kan de functionaliteit van de Sakai tools door middel van web services extern beschikbaar worden gemaakt via Axis. En hoewel deze webservices nog in ontwikkeling zijn is er in feite een solide basis gelegd om tot een goed te integreren systeem te komen. Sakai is nadrukkelijk ontworpen om als component ingezet te kunnen worden in een geïntegreerde informatievoorziening, waarbij Service Oriented Architecture (SOA) het sleutelconcept is. Binnen Sakai is voldoende aandacht voor open standaarden en specificaties. Met name op het gebied van de e-Learning specificaties zoals SCORM en de specificaties van IMS Global Learning Consortium zijn veelbelovende ontwikkelingen in gang gezet, maar is nog geen sprake van volledige ondersteuning. Het ontbreken van een betrouwbare SCORM afspeler, een wat oudere specificatie die in veel leeromgevingen al lang beschikbaar is, is teleurstellend. Omdat de door Sakai geboden functionaliteit een weerspiegeling is van de behoeften van de Sakai community kan dit overigens ook betekenen dat hier minder behoefte aan is. Hierbij moet wel opgemerkt worden dat ondersteuning van deze e-Learning specificaties over het algemeen niet in het Sakai Framework zelf zitten maar in de verschillende tools die voor dit framework ontwikkeld worden. Zo is ondersteuning van IMS Learning Design (Level A) onderdeel van een met Sakai 2.4 geïntegreerde, maar extern ontwikkelde, tool Learning Activity Management System (LAMS V2). Portfolio4u ontwikkelt samen met Kennisnet de implementatie van de IMS e-Portfolio specificatie. Bij het ontwikkelen van de demoapplicatie zijn een aantal nieuwe integratie technologieën toegepast waar we als ITBE nog weinig ervaring mee hadden. Webservices, business process modelling, open source tools en het werken in een internationale open source community waren allemaal nieuwe concepten voor ons en vormden een interessante uitdaging. De demoapplicatie laat zien dat de UT in staat is om door middel van webservices Sakai te integreren met een bestaand, in-huis ontwikkeld, systeem. Samenvattend kan gesteld worden dat Sakai uitstekend ingezet zou kunnen worden als onderdeel van een geïntegreerde leer- en werkomgeving op basis van een Service Oriented Architecture . Het SOA enabled zijn is bij Sakai niet iets wat er, zoals bij andere oudere leeromgevingen, achteraf aan is toegevoegd, maar is de basis waarop Sakai is ontworpen. Sakai is SOA by design!


Pagina 3 van 30

Summary (English) This report is the second in the series of 4 deliverables for the project pilot phase Campus Blend using Sakai (CBUS) that carried out from August 2006 until May 2007. The goal of this report is to summarize and evaluate the experiences with some technical aspects of Sakai. We focussed in particular on the technical features to integrate Sakai with other learning related ICT systems we use at our university. We did not only carry out desk research. We also got our hands dirty in making a Demonstrator application to test drive the interoperability by using web services in practice. We also wanted to get a feel for the complexity of this integration technology. We further carried out a gap analysis of the kind and level of knowledge we as an organisation need to acquire to run Sakai as a stand alone system, but also as a building block in a future integrated learning and working environment for our students and teachers. Sakai does not only distinguish itself from many other learning management systems (LMS) by it’s Open Source character. One of the main distinguishing features is the architecture of the software. Sakai has been designed with a clear Service Oriented Architecture in mind that enables geographically distributed groups of developers to work independently on the functionality of Sakai. It is this architecture that also enables optimizing functionality over multiple ICT systems. Use the functionality only once and choose the best of breed available within an organisation. If a certain function is available with better specifications or conformance in another system (for example Assessment in Questionmark Perception) this tool can be removed from Sakai (provided other tools are not dependent on it). The Sakai tools clearly are separated: there is the provision of functionality in a service and the userinterface in a seperate component. This service functionality is available in the form of a Java Application Programmers Interface (API) that can made externally available as language neutral web services using Axis. And although these webservices are still in development, a very solid foundation has been laid down to build on in the future and implement an integrated learning and working environment. Sakai has been specifically designed to function as a component in a Service Oriented Architecture (SOA). In the area of e-Learning specifications like SCORM and the IMS specifications promising developments are in progress, but there is not yet full support. The lack of a properly tested SCORM player, one of the older e-Learning specifications, is disappointing. But because the functionality offered by Sakai is a reflection of the needs of the Sakai community this might be an indication that there is obviously less of a need for it. We should also note that support for these e-Learning specifications is usually not located in the Sakai Framework itself but in the tools that are developed for this framework. For example: the IMS Learning Design (Level A) specification is supported by a tool that is well integrated, but developed in a seperate (Australian) project, Learning Activity Management Systems (LAMS V2). The Dutch company Portfolio4u is developing an implementation of the IMS ePortfolio specification in cooperation with a number of other Dutch and international organizations. In developing the Demonstrator Application we had to acquire and use new integration technologies that were new to our institution. Web services, business process modelling with ActiveBPEL, several Open Source tools and last but certainly not least working in an Open Source community where all new concepts for us and were an interesting challenge. The Demonstrator proves that we have acquired the skills needed to integrate Sakai with another, locally developed, websystem. Summarizing we can say that from a technical standpoint Sakai is excellently positioned and designed to be used as a important foundation for our future Learning System, based on SOA principles. Being SOA enabled was not added as an afterthought, as is the case in most current LMS systems. Sakai is SOA by design!


Pagina 4 van 30

1. Inleiding Dit rapport wordt opgeleverd in het project pilotfase Campus Blend using Sakai (CBUS). De technische aspecten van Sakai zijn het onderwerp van dit rapport. Een zwaar accent ligt op de interoperabiliteit van Sakai met andere systemen. Daartoe wordt in hoofdstuk 2 ingegaan op de architectuur van Sakai, zowel de intern als de extern zichtbare, in de vorm van een inventarisatie van de beschikbare webservices. In hoofdstuk 3 bespreken we hoe het Vak Informatie Systeem Twente (VIST) aangepast moest worden om een integratie met Sakai te kunnen realiseren. In hoofdstuk 4 wordt de eigenlijke integratie uiteengezet via de weg van de architectuur. Hoofdstuk 5 geeft een overzicht van de opgedane ervaring met Sakai vanuit een technisch perspectief, met daarbij ook aandacht voor ondersteuning in Sakai van (open) specificaties en standaarden.

1.1.

Integratie, ook instellingsoverstijgend

In het ELO Advies is TeleTOP, de huidige leeromgeving van de UT, op toekomstvastheid beoordeelt. Een belangrijke wens van de gebruikers van TeleTOP kwam hier naar boven: integratie tussen de verschillende ICT voorzieningen die het leren ondersteunen. Ook in bijeenkomsten met gebruikers in het CBUS project kwam deze wens tot integratie weer aan de orde. Het wordt als een knellend probleem ervaren dat dit in de huidige leeromgeving niet mogelijk is.

Figuur 1: Terugkoppeling van gebruikers: Waar is de integratie? Het ELO Advies (Koopal, Laagland, Portier, 2005) resulteerde in het advies de Open Source1 leer- en werkomgeving Sakai aan een nader onderzoek te onderwerpen. Sakai heeft een heldere op losse verwisselbare componenten gebaseerde architectuur die mogelijk een oplossing zou kunnen bieden om te komen tot de gewenste integratie met andere systemen op de UT. Deze op componenten gebaseerde architectuur is een belangrijke eigenschap van Sakai. In een rapport van het Sakai Project (Severance, 2007) wordt deze architectuur zelfs een van de sleutelkenmerken voor het huidige en toekomstige succes van Sakai genoemd: “The Sakai Architecture is one of the keys to the current and future success of Sakai. To empower hundreds of highly talented developers and deployers around the word evolving a single product with a million lines of code together, it is very important to invest in a serviceoriented framework. A service-oriented framework provides the necessary modularity and isolation to insure that the work of one developer does not inadvertently harm some other aspect of the system.” In het CBUS project hebben we in het technische werkpakket Sakai aan een nader onderzoek onderworpen om inzicht te krijgen in deze belofte.

1

Voor meer informatie over Open Source wordt verwezen naar bijlage 2.


Pagina 5 van 30

1.2.

Nadruk op integratie via architectuur

Sakai kent een aantal methoden om de gewenste integratie te verwezenlijken. Natuurlijk biedt het feit dat Sakai een Open Source product is al talloze mogelijkheden tot integratie door aanpassingen in de broncode van Sakai. Maar deze aanpassingen zullen bij iedere release van Sakai weer opnieuw aangebracht moeten worden en is niet erg toekomst vast. Er wordt geen garantie afgegeven dat de broncode in de toekomst geen fundamentele wijzigingen zal ondergaan. Ook biedt Sakai de mogelijkheid om nieuwe tools te ontwikkelen die gebruikt zouden kunnen worden voor integratie met andere systemen. Zo heeft Melete, het tool waarmee een docent interactieve leerinhoud kan produceren, de mogelijkheid om gekoppeld te worden aan externe learning object repositories, bijvoorbeeld LOREnet2 van SURF. Sakai kent zogenaamde service providers waarmee bijvoorbeeld de Sakai gebruikers directory gekoppeld kan worden aan een Student Informatie Systeem. Via een experimentele implementatie van de IMS Tools Interoperability specificatie3 kunnen tools van externe leveranciers die deze specificatie ondersteunen gekoppeld worden aan Sakai. Een voorbeeld is een gerealiseerde koppeling met het LearneXact Learning Content Management Systeem. De nadruk bij dit onderzoek ligt op de integratiemogelijkheden van Sakai via web services op basis van de architectuur van Sakai zoals die als leidraad wordt genomen voor de huidige en toekomstige ontwikkeling van Sakai. Een belangrijke doelstelling van dit onderzoek was het verwerven van inzicht in de complexiteit en toepasbaarheid van de gebruikte technologieën.

2 3

http://www.lorenet.nl http://www.imsglobal.org/ti


Pagina 6 van 30

2. Inventarisatie Sakai web services In dit hoofdstuk zal worden ingegaan op de interne en externe service oriëntatie van Sakai. We geven een overzicht van de architectuur van Sakai en de externe (web) services die geïnventariseerd zijn toelichten. Hierbij zullen we deze functionaliteit in termen van Archimate toelichten. Archimate4 is een geïntegreerde architectuuraanpak of framework en taal voor het beschrijven van bedrijfsarchitecturen en is door het samenwerkingsverband van de drie technische universiteiten, de 3TU, en daarmee ook door de UT als gereedschap gekozen voor het beschrijven van de samenhang tussen de verschillende (domeinen instellingsoverstijgende) bedrijfsprocessen. Zoals eerder al aangegeven onderscheid Sakai zich van de meeste andere leeromgevingen door een service georiënteerde architectuur.

2.1. Sakai is SOA by design Een belangrijke ontwerpkeuze voor Sakai is de service oriëntatie (Severance, 2007). Dat wil zeggen dat de functionaliteit van Sakai geleverd voor een belangrijk deel geleverd wordt door tools, die intern een heldere opzet of architectuur hebben. De functionaliteit wordt ondergebracht in een Service component die alleen via een Application Programmers Interface (API) afgenomen mag worden. Tools kunnen dus elkaars functionaliteit gebruiken, maar alleen via de gedocumenteerde API en niet, zoals veel gezien wordt, door rechtstreeks functies in de interne code aan te roepen. Zo kan een tool van een nieuwe betere service implementatie voorzien worden zonder dat service afnemende tools hier hinder van ondervinden. De gebruikersinterface wordt gerealiseerd door een aparte module, aangegeven met Tool A en Tool B in onderstaande figuur. De rechtstreekse toegang tot het onderliggende data model van een tool service is verboden. Kennis van bijvoorbeeld bepaalde velden in de database mag niet gebruikt worden. Op deze manier kan een nieuwe tool functionaliteit van bestaande tool services hergebruiken zonder afhankelijk te zijn van de interne opzet. Een nieuwe Vidcast tool bijvoorbeeld kan voor het plaatsen van de bestanden gebruik maken van de services van het Resource Tool. Hiermee is intern ook ontdubbeling van functionaliteit gerealiseerd.

Figuur 2: Sakai’s componenten- en services architectuur Sakai kent inmiddels een rijke hoeveelheid tools en interne service API’s waarmee een aanzienlijk deel van de functionaliteit beschikbaar is voor de ontwikkeling van nieuwe tools.

4

Zie: http://www.archimate.org


Pagina 7 van 30

2.2. Overzicht van de Sakai architektuur De in de vorige paragraaf beschreven componenten- of service architectuur van de tools is de basis voor de gehele architectuur van Sakai zoals weergegeven in figuur 2. De verzameling services met bijbehorende API’s vormen de zogenaamde Sakai Components. Via de service API’s leveren de Tools het zichtbare gebruikersinterface. Deze gebruikerinterface (Sakai zoals de meeste docenten en studenten het zullen ervaren) kan overigens ook weer via meerdere methoden ontsloten worden, maar bijna altijd via een eigen of de ingebouwde portal.

Figuur 3: Overzicht Sakai 2.0 Architectuur: Maar de component services worden ook gebruikt om extern functionaliteit ter beschikking te stellen. Hiervoor wordt gebruik gemaakt van Axis5, een zogenaamde SOAP6 stack die de interne Java API’s ‘vertaalt’ naar een platformonafhankelijk XML formaat en daarmee de basis vormt voor de externe integratie voorzieningen van Sakai. De functionaliteit van de zichtbare Sakai tools zijn het onderwerp van rapport C (Hilderink, Peters, Portier, Slotman, 2007), waarin de functionaliteit en onderwijskundige aspecten van Sakai beoordeeld worden. In de rest van dit rapport beperken we ons tot de interne en externe services van Sakai en de manier waarop deze in een bredere onder architectuur ontwikkelde integratie ingezet kunnen worden. In het linker deel van figuur 3 is aangegeven dat de services in een aantal gevallen voorzien zijn van zogenaamde providers (‘Role, Realm, Course providers’). Een provider van een service is een soort van indirectie om de standaard koppeling naar het onderliggende informatie model te omzeilen en te routeren naar een andere informatiebron. Dit is ook een manier om integratie tot stand te brengen (bijvoorbeeld single logon) maar op een laag technisch niveau en niet op basis van de services architectuur, die hiermee overigens niet in conflict is.

5

Zie: http://ws.apache.org/axis/ SOAP: Simple Object Access Protocol, een techniek om functionaliteit via het internet beschikbaar te maken aan andere applicaties.

6


Pagina 8 van 30

Figuur 4: Vereenvoudiging van het architectuur overzicht: Services In de verdere bespreking zullen we deze voorziening niet meenemen en daarmee wordt het overzicht van Sakai vereenvoudigd tot die zoals in figuur 4 rechts is aangegeven. De Sakai services worden overigens nog wel in een aantal functionele categorieën ingedeeld, zoals Common Services, Application Service en Framework Services, maar vanuit het oogpunt van architectuur is deze indeling niet relevant.

2.2.1. Archimate Archimate is een architectuurtaal en een verzameling visualisatietechnieken om de samenhang en de relaties tussen de processen en domeinen van een instelling in kaart te brengen. Archimate is door de 3TU en SURFfoundation gekozen als gereedschap om de architectuur van in eerste instantie de domeinen Student en Onderwijs in kaart te beschrijven. Om deze reden zal in de rest van dit rapport getracht worden de beschrijvingen van Sakai en de integratie demo te presenteren in Archimate concepten. Archimate beschrijft deze met ICT ondersteunde zogenaamde Enterprise Architectuur in drie lagen: de Business laag, waarin de bedrijfsprocessen en actoren beschreven worden, de Applicatielaag waarin de ondersteunende ICT applicaties beschreven worden en tenslotte de Technologielaag, waar de applicatielaag ondersteunende functies (servers, databases, netwerken etc.) beschreven worden. We beperken ons hier tot de Businesslaag en de Applicatielaag. Hierin worden de processen en applicaties beschreven in termen van componenten die services leveren en extern beschikbaar stellen via een service interface. Deze componenten bestaan op hun beurt weer uit kleinere eenheden, de applicatie functies. Voor een korte toelichting wordt verwezen naar de inleiding op Archimate (Lankhorst, 2005).

Figuur 5: Archimate lagen model


Pagina 9 van 30

2.2.2. Sakai Application Services: We kunnen de services architectuur van Sakai zoals die in figuur 4 is weergegeven ook in Archimate termen weergeven. Archimate gebruikt andere termen om de verschillende concepten aan te duiden. Sakai wordt dan een application component genoemd. De interne services die de functionaliteit voor de Sakai tools leveren via de API’s worden in Archimate application functions genoemd. De extern (voor andere applicatie componenten) zichtbare services worden application services genoemd. Deze externe application services worden functioneel beschreven door een zogenaamd application service interface. Dit application service interface heeft in de meeste gevallen (en zeker bij Sakai) de vorm van een Web Service Description Language document (WSDL).

Figuur 6: Sakai Architectuur in Archimate concepten Belangrijk is op te merken dat in theorie Sakai dus zowel intern en extern componenten service georiënteerd is. Hierin onderscheidt Sakai zich van andere leer- en werkomgevingen als Moodle en TeleTOP. Moodle is bijvoorbeeld wel intern component georiënteerd maar niet extern, TeleTOP is noch intern noch extern component georiënteerd. Deze heldere en veelbelovende architectuur is voor een deel nog conceptueel. Bij het ontwerpen van Sakai is in het begin veel nadruk gelegd op de interne architectuur en de extern zichtbare tools zodat snel een met bijvoorbeeld Blackboard vergelijkbare functionaliteit aan de gebruikers aangeboden kon worden (Severance, 2006). De externe beschikbare functionaliteit is nog een werk in wording en is matig gedocumenteerd. Een vorm van ‘backward engineering’ om inzicht te krijgen in deze functionaliteit was een onderdeel van de werkzaamheden in CBUS. De services worden hier globaal beschreven om een illustratie te geven van de functionaliteit. Een meer uitgebreide beschrijving is te vinden op de projectwiki7. De figuren 7 tot en met 10 geven een grafische weergave van het zogenaamde service interface. Een abstracte service wordt via een binding (bijvoorbeeld SOAP via HTTP) concreet aanspreekbaar gemaakt. Een service kan verschillende operaties ondersteunen die door middel van PortTypes gegroepeerd kunnen worden. Alle Sakai services worden via SOAP over HTTP aanspreekbaar gemaakt.

2.2.3. SakaiLogin SakaiLogin is een eenvoudige service waarmee extern ingelogd kan worden op Sakai. Zoals docenten en studenten die Sakai willen gebruiken zich moeten identificeren, moeten ook applicaties die functionaliteit van Sakai willen gebruiken via de externe web services zich identificeren door in te loggen via de SakaiLogon service.

7

http://www.sakai-pilot.utwente.nl/sakaiwiki/sakaiscript


Pagina 10 van 30

Figuur 7: SakaiLogin application service overzicht

2.2.4. SakaiScript SakaiScript is een rijke verzameling operaties voor het beheer van Sakai gebruikers en sites.

Figuur 8: SakaiScript application service overzicht

2.2.5. SakaiSession SakaiSession is een eenvoudige voorziening om Sakai sessie en gebruikers informatie op te vragen en te valideren.

Figuur 9: SakaiSession application service overzicht

2.2.6. SakaiSite SakaiSite geeft toegang tot Sakai site beheer en de bijbehorende tools.

Figuur 10: SakaiSite application service overzicht


Pagina 11 van 30

3. Sakai en VIST integreren Omdat we integratie willen aantonen tussen applicaties hebben we gekozen voor een eenvoudige integratie tussen Sakai en het Vak Informatie Systeem Twente, VIST.

3.1. Applicatie Service op VIST Omdat VIST zoals veel van de systemen op de UT niet voorzien is van externe applicatie services hebben we in het kader van dit onderzoek een eenvoudige applicatie service ontwikkeld op VIST.

Figuur 11: Huidige VIST zonder application service Het huidige VIST wordt via een web interface door studenten geraadpleegd bij het oriënteren op vakinformatie en via een Oracle Forms client applicatie door medewerkers van bureau Onderwijszaken ‘gevuld’ met vakinformatie. Er is een eenvoudige externe service interface ontworpen waarmee op basis van een vakcode gezocht kan worden in de VIST database en een XML document teruggeven wordt met een vakcode, vaktitel en vakbeschrijving.

Figuur 12: Huidige VIST met application service

Figuur 13: VIST application service beschrijving


Pagina 12 van 30

3.2. Open Standaarden en specificaties: XCRI Zoals bekend is, is voor interoperabiliteit ook ondersteuning van e-Learning en andere specificaties en standaarden nodig (meer details hierover in hoofdstuk 5). Er moet immers informatie uitgewisseld worden tussen applicaties die doorgaans van verschillende leveranciers afkomstig is en die en met verschillende technologieën ontwikkeld zijn (Java, C++, PHP). Voor veel soorten informatie zijn er afspraken, maar voor bijvoorbeeld de beschrijving van vakken zijn er nog geen standaarden. Er is een potentiële kandidaat in ontwikkeling bij het door JISC gesponsorde project XCRI. XCRI staat voor eXchanging Course Related Information. Een 1.0 versie van het datamodel is inmiddels opgeleverd inclusief XML binding van het datamodel waarmee vakken en hele curricula inclusief roosterinformatie kan worden beschreven en uitgewisseld. XCRI zal waarschijnlijk ingebracht worden bij het specificatie proces van IMS Global Learning Consortium8 (IMS) waar veel e-Learning specificaties beheerd worden. De application service die op VIST is aangebracht is voorzien van een vereenvoudigde variant van XCRI. Hierin worden alleen de vakcode, vaktitel en vakbeschrijving (die uit de VIST database worden gehaald) in XCRI XML formaat worden afgeleverd. XCRI is ook een interessante kandidaat voor de uitwisseling van vakinformatie in 3TU verband, maar zal daarvoor een zogenaamde profilering slag moeten ondergaan om afstemming te realiseren met de lokale vakinformatie systemen.

3.3. Integreerbaar: Sakai en VIST voorzien van externe application services Met de inventarisatie en de beschrijving van de application services van Sakai en het aanbrengen van een application service hebben we twee application componenten die integreerbaar zijn.

Figuur 14: VIST en Sakai met externe application services: klaar voor integratie Daarmee is nog geen sprake van geïntegreerd zijn. Eigenlijke integratie moet nog gerealiseerd worden en is nadrukkelijk geen ‘zero effort’ proces! Deze eigenlijke integratie is het onderwerp van hoofdstuk 4.

8

http://www.imsproject.org


Pagina 13 van 30

4. Beschrijving demoapplicatie Voor het integreren van Sakai en VIST is uitgegaan van een eenvoudig businessproces dat applicatieoverstijgend (en domeinoverstijgend) is. Voor de illustratie van het proces zullen we weer gebruik maken van de Archimate taal- en visualiseringselementen.

4.1. Het businessproces Een medewerker, in zijn rol als docent, gaat een nieuw vak geven. Het vak is door de betreffende validatie commissie positief beoordeeld en kan gepubliceerd worden in het vak informatie systeem VIST. Daartoe gaat de docent met de relevante gegevens (vaktitel, beschrijving, vereiste voorkennis etc.) naar Bureau Onderwijszaken (BOZ) die in dit proces in de rol van beheerder van de vakinformatie optreedt. De docent maakt gebruik van een applicatie waarmee de vakinformatie ingevoerd kan worden (d.m.v. de Registratie service) en die daarmee beschikbaar is voor raadpleging door studenten. Na registratie van de gegevens wordt een acceptatie service aangeroepen die via een Docent Informatie Service de docent kan melden dat het vak geregistreerd is. Deze twee services worden nu in feite geleverd door VIST. In een geautomatiseerd vervolgproces willen we op basis van de in VIST geregistreerde vakinformatie een vakondersteunende site in Sakai aanmaken, waarbij de vakcode, vaktitel en de vakbeschrijving overgenomen worden uit VIST (de Instantiatie Service in figuur 15). De aangemaakte site kan volgens een gekozen template gevuld worden (Vakomgeving Vullen Service).

Figuur 15: Integratie van VIST en Sakai t.b.v. een eenvoudig bedrijfsproces Voor de demoapplicatie is alleen het tweede deel van het proces met de twee business services ‘Instantiatie’ en ‘Vakomgeving vullen’ geïmplementeerd en in de vorm van een


Pagina 14 van 30

(Business Process Execution Language) proces gerealiseerd9. Met de demoapplicatie kan op basis van een eerder gevonden vakcode via de application service op VIST relevante vakinfo opgehaald worden, die eventueel gewijzigd kan worden in de demoapplicatie. Deze informatie wordt gebruikt voor het aanmaken van de Sakai site. In een productiesetting zou dit proces automatisch getriggerd worden door de client applicatie van VIST waarmee een BOZ medewerker vakinformatie invoert.

4.2. Demoapplicatie in Archimate lagen Archimate kent naast de business- en de applicatielaag nog de technologielaag en de omgeving. Deze twee lagen zijn in figuur 16 nog aangebracht maar verder niet uitgewerkt omdat ze vanuit architectuur perspectief in dit verband niet relevant zijn. De technologielaag bevat bijvoorbeeld de Oracle database waar VIST de vakinformatie in opslaat, de Oracle database die we voor de database server van Sakai gebruiken en alle andere technische infrastructuur.

Figuur 16: Bedrijfsproces met alle Archimate lagen

4.3. Demoapplicatie in Archimate lagen aangevuld met SOA ESB Er ontbreekt nog iets in het Archimate lagen model zoals dat in figuur 16 is weergegeven. Dit is een bijzonder element dat uit oogpunt van architectuur minder belangrijk is, maar dat bij de keuze voor een Service Oriented Architecture als ontwerpprincipe van de beschreven bedrijfs- en applicatiearchitectuur wel erg belangrijk is, namelijk de Enterprise Service Bus. 9

Zie bijlage 5: BPEL Modelling met ActiveBPEL


Pagina 15 van 30

Deze component wordt in de demoapplicatie niet gebruikt, maar zal in een productie setting wel een cruciale rol moeten vervullen bij het koppelen van de verschillende services, zowel in de businesslaag als de applicationlaag. In feite zullen alle verbindingen tussen de externe services en de afnemende (BPEL) processen via deze ESB lopen. Ook Quality of Service, beveiliging, het beheer en de monitoring van de services en de processen is een belangrijk onderdeel van een productieomgeving

Figuur 17: De missing link bij een SOA implementatie: de Enterprise Service Bus

4.4. Integratie onder architectuur In de vorige hoofdstukken hebben we uiteengezet dat voor het integreren van de verschillende informatiesystemen die het onderwijs ondersteunen niet alleen integreerbare systemen nodig zijn maar dat ook de gewenste integratie vastgelegd moet worden in de vorm van procesbeschrijvingen. Deze verzameling procesbeschrijvingen in termen van bedrijfsservices die uiteindelijk afgebeeld worden op de applicatie services vormen de bedrijfslaag van de architectuur zoals die in figuur 17 is weergegeven. Bedrijfsprocessen zullen in toenemende mate niet alleen applicatieoverstijgend, maar ook domeinen zelfs instellingsoverstijgend zijn. En services, of het nu bedrijfs- of applicatieservices zijn, zullen we zoveel mogelijk willen hergebruiken in meerdere processen uit oogpunt van kostenbeheersing en efficiëntie. Dit impliceert dat over alle processen, services, en datamodellen afspraken gemaakt zullen moeten worden om dit hergebruik mogelijk te maken. Afspraken niet alleen met betrekking tot de techniek, maar ook zaken als inrichting en eigenaarschap van processen en services zullen gemaakt moeten worden. Ook De techniek van Sakai Campus Blend using Sakai: rapport B

Pagina 16 van 30

de beschrijvingen zelf zullen gestandariseerd moeten worden. Met UML? Archimate? Hoe worden de datamodellen vastgelegd? Wie bepaalt welke specificatie gebruikt wordt en wanneer op een nieuwere versie wordt overgestapt? En als we al een bepaalde specificatie of standaard hebben gekozen zullen er afspraken gemaakt moeten worden over de waardenverzameling die we gebruiken voor de invulling (applicatieprofiel). Als voorbeeld de vakcode die we in 3TU verband kiezen bij het invullen van vakbeschrijvingen in XCRI formaat. Die heeft nu bij iedere instelling een ander formaat. Daar zal afstemming over moeten worden bereikt willen we instellingsoverstijgend vakinformatie kunnen raadplegen. Al deze aspecten vormen het domein van de Enterprise Architectuur. Onder architectuur gaan werken is natuurlijk al eerder gedaan door andere organisaties. En daarbij is veel kennis opgedaan, zijn veel fouten gemaakt en is er een rijke verzameling van best practices, modellen, gereedschappen. Veel processen zijn niet uniek voor het onderwijs, maar soms slechts kleine variaties op een bestaand proces. Een dergelijke verzameling van tools, best practices en modellen wordt een Architectuur Framework genoemd. Er zijn meerdere architectuur frameworks. In 3TU verband is gekozen voor The Open Group Architecture Framework (TOGAF) als basis voor het ontwikkelen van de architectuur van de 3TU. De TOGAF bevat naast de verzameling best practices, tools en een database van standaarden en specificaties ook de Architecture Development Method (ADM), een in de praktijk getoetste methodiek om in een cyclisch en iteratief doorlopen proces van 8 fasen te komen tot een bedrijfsarchitectuur. Hiermee wordt architectuur in de breedste zin van het woord bedoeld. Niet alleen de ICT architectuur, maar ook bijvoorbeeld de inrichting van de architectuur governance, en de bestuurbaarheid en beheersbaarheid van het hele architectuurproces. De relatie tussen de TOGAF en het Archimate lagen model is weergegeven in figuur 18.

Figuur 18: Integreren onder architectuur: relatie met het TOGAF


Pagina 17 van 30

5. Ondersteuning open standaarden Binnen het project is onderzoek verricht naar de ondersteuning van Sakai van (open) specificaties en standaarden. De synthese hiervan volgt in dit hoofdstuk. In de vorige hoofdstukken kwam een specificatie aan de orde die nog in ontwikkeling is, namelijk XCRI.

5.1. Visie Er is binnen de Sakai community voldoende aandacht voor open standaarden en specificaties. Er is een zeer duidelijke visie (Severance, Hardin, 2006) op ondersteuning van open specificaties en standaarden. De visie is dat Sakai zowel met meer ‘algemene’ specificaties goed overweg moet kunnen, als met meer specifieke elearning specificaties. Sakai moet eigenlijk leidend worden op termijn. De verwachting is dat commerciële aanbieders in dit opzicht niet voorop zullen lopen, omdat goede ondersteuning van specificaties en standaarden in essentie de ‘vendor lockin’ zal ondergraven van deze aanbieders.

5.2. Ondersteuning algemene specificaties Figuur 19 schetst de toekomstvisie voor ondersteuning van meer ‘algemene’ standaarden. De huidige ondersteuning is al zeer goed te noemen, maar het zal dus nog beter worden in de toekomst.

Figuur 19: Sakai als Swiss Army Knife (algemene specificaties) In Sakai, versie 2.3, worden de volgende specificaties en standaarden daadwerkelijk ondersteund: • JSR-168 Portal Specification (beta) • OASIS WSRP 1.0 Alpha versie (beta) • W3C XML 1.0 Sakai Config & Data Description bestanden • W3C HTTP 1.1 • W3C HTML 4.01 • W3C SOAP 1.2 • W3C WSDL 1.1 • W3C XML XPath 1.0 • Open Knowledge Initiative Service Interfaces


Pagina 18 van 30

5.3. Ondersteuning elearning specificaties Wat betreft elearning specificaties en standaarden valt de evaluatie minder gunstig uit. Het projectteam heeft bijvoorbeeld ervaren dat er nog niet voldoende ondersteuning is van de SCORM-specificatie10 (zie bijlage 1). Het ontbreken van een betrouwbare SCORM afspeler, een wat oudere specificatie die in veel leeromgevingen al lang beschikbaar is, is teleurstellend. Aangezien de door Sakai geboden functionaliteit een weerspiegeling is van de behoeften van de Sakai community kan dit overigens ook betekenen dat hier minder behoefte aan is. Er zijn op het gebied van de elearning specificaties van het IMS Global Learning Consortium11 veelbelovende ontwikkelingen in gang gezet, maar is nog geen sprake van volledige ondersteuning. Opgemerkt dient te worden dat elearning specificaties meestal op een bepaald gebied gedefinieerd zijn, wat zich in Sakai vertaald in het feit dat de ondersteuning door een bepaalde tool (een functie) ondersteund wordt, of zou moeten worden. De analyse van Sakai 2.3 resulteert in het volgende lijstje: • SCORM 2004: contributed beta (niet stabile) • IMS Common Cartridge: prototype • IMS Content Packaging: in Melete • IMS Question & Test Interop.: in Samigo • IMS Learning Design: via LAMS • IMS Learner Information Profile: SIS • IMD Metadata: in IMS CP en SCORM • IMD Enterprise: in Sakai database Een recente ontwikkeling in dit verband is dat in Nederland de e-Portfolio specificatie verder doorontwikkeld wordt. Portfolio4u heeft dit opgepakt, samen met Kennisnet.

10 11

http://www.adlnet.gov/scorm http://www.imsproject.org


Pagina 19 van 30

6. Ervaringen met Sakai Dit hoofdstuk gaat in meer detail over ervaringen met Sakai vanuit een technisch perspectief.

6.1. Sakai in gebruik op de UT 6.1.1. Installatie en configuratie Een OOTB (out of the box) installatie van Sakai met een Oracle database was eenvoudig te realiseren. Als server platform is hierbij gebruik gemaakt van SUSE Linux Enterprise Server 9 Voor de pilots zijn er koppelingen gemaakt met een LDAP server voor de persoonsgegevens en met een Oracle SSO (single sign-on) server voor de authenticatie. Deze koppelingen waren eenvoudig te realiseren met bestaande Sakai functionaliteit. Verdere wijzigingen zoals het aanpassen van het uiterlijk en tekstuele meldingen waren eenvoudig in de source code aan te brengen. Deze wijzigingen zijn met behulp van het versiebeheersysteem Subversion bijgehouden.

6.1.2. Performance Tijdens het gebruik van de 2.2.0 versie van Sakai waren er enkele performance problemen. Dit bleek later veroorzaakt te worden door een bug (memory leak) in een onderdeel van Sakai. Dit probleem was in versie 2.2.1 verholpen. Na de upgrade van de pilot server van versie 2.2.0 naar versie 2.3.1(de tussenliggende versies hebben we overgeslagen) waren deze performance problemen inderdaad verholpen. Een belangrijk aspect bij de performance van Sakai bleek te liggen in de JVM (Java Virtual Machine) tuning. De nieuwe Java 5.0 versie versimpelt dit enigszins, maar enige kennis betreft JVM tuning is toch een must voor een soepel draaiende Sakai installatie. Tijdens de pilots heeft slechts een beperkte groep gebruik gemaakt van de Sakai server. De tijdens de pilots ondervonden performance hoeft dus niet representatief te zijn voor de performance indien Sakai campusbreed uitgerold zou worden. Er zijn echter al instellingen die Sakai inzetten voor meer dan 100.000 studenten. Hier worden dan ook geen problemen verwacht.

6.1.3. Beheer De beheerstaken tijdens de pilots waren minimaal. Basis taken zoals het toekennen van rechten voor bestaande sites waren eenvoudig uit te voeren.

6.1.4. Updates Security updates worden via een speciale members-only lijst verspreid voordat ze publiek worden gemeld. Deze updates bestaan meestal uit een set van wijzigingen aan de source code. Deze kunnen via het code versiebeheersysteem Subversion worden toegevoegd aan de lokale source code en kunnen na compilatie op de server worden geïnstalleerd. Overige verbeteringen worden gebundeld en via release versies verspreid. Het is echter ook mogelijk om losse verbeteringen over te nemen, zelfs voordat deze officieel in een nieuwe release versie zijn uitgebracht.

6.1.5. Upgrade Sakai versie tijdens pilot In de definitiefase van CBUS is gebruik gemaakt van Sakai versie 2.1.2. De pilots zijn uiteindelijk van start gegaan met Sakai versie 2.2.0. Tijdens de pilots is besloten om een upgrade uit te voeren van 2.2.0 naar 2.3.1. Deze nieuwe versie bevatte zowel nieuwe tools als bugfixes voor bestaande tools. Tevens was het een goede manier om praktijkervaring op te doen met release versie upgrades van Sakai. De upgrade is uitgevoerd als een source code upgrade, waarbij de wijzigingen van Sakai versie 2.2.0 naar 2.3.1 via het versiebeheersysteem Subversion semi-automatisch samengevoegd zijn met de wijzigingen die we voor de UT versie op Sakai 2.2.0 aangebracht hadden. Hierdoor konden de eigen aanpassingen eenvoudig worden meegenomen naar de nieuwe versie. Voor de database waren upgrade scripts beschikbaar. Het gehele upgrade proces verliep soepel en er zijn geen problemen ontstaan tijdens of na de upgrade.


Pagina 20 van 30

6.2. Ontwikkelen van nieuwe functionaliteit in Sakai Sakai kan op vele manieren uitgebreid worden. Nieuwe functionaliteit wordt als ‘tools’ uitgevoerd. Services kunnen aangepast of vervangen worden om informatie uit een ander bron systeem te halen. Om een nieuwe tool te kunnen ontwikkelen in Sakai heeft een ervaren Java ontwikkelaar, afhankelijk van zijn voorkennis en de complexiteit van de te ontwikkelen tool, naar schatting 2-6 weken inwerktijd nodig. Het ontwikkelen van functionaliteit als Sakai tools kost over het algemeen meer tijd dan het ontwikkelen van soortgelijke functionaliteit als een ‘standalone JSP/Servlet web applicatie’ met behulp van een eenvoudig MVC framework (zie ook bijlage 4). Door logica in herbruikbare services onder te brengen kan op de langere termijn echter tijd bespaard worden. Tevens kan door hergebruik van logica met services een verlaging van de totale onderhoudskosten worden gerealiseerd. Twee belangrijke hulpmiddelen voor softwareontwikkelaars binnen de Sakai community (en andere open source communities) zijn Eclipse en Subversion. Beide tools zijn zelf ook open source en dus vrij te gebruiken.

6.2.1. Eclipse Er is geen verplichte Integrated Development Environment (IDE) voor Sakai, in principe zou elke tekst editor al kunnen voldoen. Eclipse is echter de voorkeur IDE in de Sakai community. Eclipse is een volwassen open source IDE met een open plugin structuur. Dankzij de plugin structuur en de grote beschikbaarheid van plugins (zowel commercieel als open source) is Eclipse zeer geschikt voor een verscheidenheid aan taken. Voorbeelden van plugins zijn: web service end point en client generatie, XML editors, visuele BPEL (Bussiness Process Execution Language) modellering, code versiebeheer en J2EE applicatie server integratie. In vergelijking met een commerciële IDE als Oracle JDeveloper lijkt Eclipse geschikter voor grote / complexe projecten als Sakai. Voor gebruik in kleine projecten is JDeveloper wellicht eenvoudiger in gebruik. In bijlage 3 meer informatie over Eclipse.

6.2.2. Subversion Subversion is een open source versiebeheersysteem. De Sakai Foundation gebruikt een centrale Subversion repository voor het versiebeheer van de Sakai source code. Voor de pilots heeft de UT een eigen repository op gezet. In deze lokale repository worden eigen wijzigingen aan de source code bijgehouden. Om bij te blijven met de voortgang van Sakai in de centrale repository kunnen Updates en security fixes (selectief) overgehaald worden naar de lokale repository. Het gebruik van een versiebeheersysteem zoals Subversion is essentieel met meerdere ontwikkelaars gezamenlijk te kunnen ontwikkelen aan Sakai. Tevens is het essentieel om de lokale wijzigingen tegenover de basis versie van de Sakai code zoals deze door de community wordt beheerd bij te houden, dit maakt het mogelijk om de lokale wijzigingen mee te kunnen nemen naar nieuwe release versies van Sakai. Het werken met een versiebeheersysteem brengt wel enige extra overhead en complexiteit met zich mee. Het is echter een onmisbaar deel van een professionele ontwikkelstraat, zeker voor een complex open source systeem als Sakai.

6.3. Open Source en Sakai 6.3.1. Licentie Sakai wordt beschikbaar gemaakt onder de Educational Community License 1.0. Deze licentie geeft vrije toegang tot de source code. In tegenstelling tot bijvoorbeeld de GNU GPL licentie verplicht deze je niet om afgeleid werk (bijvoorbeeld eigen functionaliteit) onder de zelfde licentie vrij beschikbaar te stellen.

6.3.2. Community De Sakai (ontwikkelaars) community is een wereldwijde community waarin zowel mensen uit commerciële bedrijven als uit onderwijsinstellingen actief zijn.

6.3.3. Communicatiekanalen De community communiceert hoofdzakelijk via 3 virtuele communicatiemiddelen. De techniek van Sakai Campus Blend using Sakai: rapport B

Pagina 21 van 30

1. Sakai Collab (http://collab.sakaiproject.org/portal) is een instantie van Sakai die gebruikt wordt om samen te werken aan de ontwikkeling van Sakai. Vooral de ’email archive’ functionaliteit wordt vaak gebruikt voor mailing lists. Ondanks de mogelijkheden van communiceren via meerdere sites / lijsten in Sakai collab verloopt veel van de ontwikkelaarsgerelateerde communicatie via de ’dev-list’ email archive. Het grote aantal postings hier is echter zelfs te groot voor de Sakai email archive tool zelf. De ’dev-list’ kan het beste via een externe website worden gevolgd of doorzocht: http://news.gmane.org/gmane.comp.cms.sakai.devel. 2. Sakai Confluence (http://bugs.sakaiproject.org/confluence/dashboard.action) is een Wiki waar documentatie en rapportage van tools, discussiegroepen en werkgroepen te vinden is. 3. Sakai Jira (http://bugs.sakaiproject.org/jira/secure/Dashboard.jspa) is een bug / issue tracker. Hier worden bugs aangemeld en ondernomen acties teruggemeld, inclusief verwijzingen naar de revisies waar de problemen verholpen zijn.

6.3.4. Werken in de community Vragen aan de community worden over het algemeen binnen een paar dagen beantwoord door zowel werknemers van de Sakai Foundation, als door mensen die werken bij een instelling / bedrijf waar Sakai in gebruik is. De antwoorden zijn meestal bruikbaar en behulpzaam.

6.3.5. Documentatie Evenals bij veel andere open source projecten is bij Sakai de documentatie onvolledig of verouderd. Dit geldt zowel voor technische documentatie als voor documentatie voor eindgebruikers. Er heerst soms een ‘als iemand meer wil weten dan moet hij/zij het maar vragen’ cultuur. Veel vragen belanden uiteindelijk op de ‘sakai-dev’ lijst, waar ze meestal wel redelijk vlot beantwoord worden.


Pagina 22 van 30

7. Bronnen Hilderink, M.A., Peters, E.M.A., Portier, S.J., Slotman, K.M.J. (2007). Deelrapport C: Functionaliteit en onderwijskundige mogelijkheden. Kenmerk: ITBE 07/10136. Universiteit Twente. Koopal, W.Y., Laagland, E.F. & Portier, S.J. (2005). ELO Advies. http://www.utwente.nl/elo/resultaten/eindrapporteloadvies.pdf. Kenmerk: ITBE/05/10397/wsl. Geraadpleegd op 18 juni 2007. Lankhorst, M.M. (ed.) (2005). Introduction to the ArchiMate Language: the ArchiMate Language Primer. Enschede, Telematica Instituut. https://doc.telin.nl/dscgi/ds.py/Get/File43839. Geraadpleegd op 20 juni 2007. Publicatienummer: TI/RS/2004/024. Portier, S.J, & Peters, E.M.A. (2005). Verslag van een webenquête naar wenselijke veranderingen in het UT onderwijs: Volstaan de huidige ICT voorzieningen? Project ELO Advies. Kenmerk: ITBE DOC 05-02. 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. Project ELO Advies Rapport B. Kenmerk: ITBE 05/10226. Universiteit Twente. Severance, C. (2006). Sakai Project Report: The Evolution of the Sakai Architecture. Draft. http://www-personal.umich.edu/~csev/papers/2006/2006_07_arch_history_v02.doc. Geraadpleegd op 20 juni 2007. Severance, C., Hardin, J (2006). Strategic Directions for Sakai and Data Interoperability. http://www-personal.umich.edu/~csev/papers/2006/2006_07_Roadmap_Interop.pdf . Geraadpleegd op 18 juni 2007.


Pagina 23 van 30

Bijlage 1: SCORM trial In eerste instantie was voorzien dat we een test zouden uitvoeren met de in ontwikkeling zijnde SCORM afspeler van Sakai. SCORM staat voor Sharable Content Object Reference Model en is een verzameling standaarden en specificaties voor webgebaseerde leermaterialen. Veel elektronische leeromgevingen ondersteunen deze standaard al en er is al veel leermateriaal in dit formaat ontwikkeld, bijvoorbeeld in het kader van projecten van de Digital Universiteit. De opzet was om een trial te doen met een op de UT ontwikkelde webgebaseerde cursus Methodisch En Efficiënt Wetenschappelijke Informatie Zoeken (MEEWIZ). Deze cursus wordt nu nog met een eenvoudige SCORM emulator met beperkte functionaliteit aangeboden. Ook de versie van TeleTOP die de UT op dit moment gebruikt ondersteunt geen SCORM. De SCORM afspeler van Sakai is nog in de alpha fase en is dus nog geen vast onderdeel van de Sakai uitlevering. Dit betekent dat nog niet alle benodigde functionaliteit geïmplementeerd is. Ook is de afspeler alleen geschikt voor SCORM 2004 leerinhoud en niet voor het nog steeds wijdverspreide SCORM 1.2 formaat. Het is ons niet gelukt een betrouwbaar functionerende SCORM afspeler op onze Sakai server te installeren. De SCORM afspeler was functioneel nog niet volwassen genoeg om de SCORM content af te spelen. Tevens bleek er een compatibiliteitsprobleem met de door ons gebruikte Oracle database. Omdat de ontwikkeling van de SCORM afspeler een aantal maanden stilgelegen heeft kon er ook geen tijdige ondersteuning van de ontwikkelaars gekregen worden. Af en toe worden er pogingen ondernomen de haperende ontwikkeling door te starten maar de ondersteuning van SCORM lijkt onvoldoende draagvlak bij de onwikkelcommunity van Sakai te hebben. Er zijn op dit moment ligt het niet in de verwachting dat er in 2007 nog activiteiten op dit gebied ontplooid zullen worden12.

12

Bron: mail van Jon Goronno, 18 maart 2007 naar de Sakai Workgroup SCORM op Collab


Pagina 24 van 30

Bijlage 2: Wat is Open Source? Wat is open source? Open source beschrijft de praktijk die in productie en ontwikkeling vrije toegang geeft tot de bronmaterialen (de source) van het eindproduct. Voor software betekent dit vrije toegang tot de broncode van het product. Afhankelijk van de gebruikte licentie ben je soms ook verplicht om aanpassingen in de source code (afgeleid werk) onder de zelfde licentie vrij beschikbaar te stellen (bv. GPL). Andere licenties waaronder de ECL 1.0 licentie, waar Sakai onder valt, stelt deze eis niet.

Wat zijn de voordelen van open source? Open source geeft je de vrijheid om zelf aanpassingen te maken aan het product, zonder dat hier toestemming voor moet vragen van de leverancier of hoeft te wachten tot de leverancier deze wijziging doorgevoerd heeft. Soms zijn leveranciers überhaupt niet bereid om de gewenste wijzigingen door te voeren, omdat deze niet overeenkomen met het geplande pad van het product.

Wat zijn de nadelen van open source? Sommige commerciële software pakketten komen met een ondersteuningsbelofte van minimaal een bepaal aantal jaren. Een dergelijke belofte ontbreekt bij veel open source producten. Echter, omdat de source vrij is, is het product voor verdere ontwikkeling niet direct afhankelijk van een enkele organisatie. Ze kan en mag theoretisch door eenieder doorontwikkeld worden. De meeste commerciële producten hebben een redelijk heldere lijn van ontwikkeling, dit mede doordat er slechts één eigenaar is. Een nadeel bij de lijn die commerciële bedrijven hanteren is dat je er vaak weinig of geen invloed op kunt uitoefenen. Bij sommige open source producten is de lijn van ontwikkeling onduidelijk. In het geval van Sakai wordt deze lijn uitgestippeld door de Sakai Foundation.

Hoe kun je als onderwijsinstelling baat hebben bij open source? Een duidelijk voordeel van open source is natuurlijk dat er geen licentiekosten zijn. Hier staan vaak wel hogere implementatie kosten tegenover. Er valt echter winst te behalen door wijzigingen niet individualistisch aan te pakken maar er van uit te gaan dat wanneer je zelf behoefte aan bepaalde functionaliteit hebt, dat er ook anderen zijn met dezelfde behoefte. Door samen te werken kunnen kosten worden bespaard. Indien de wijzigingen door de community worden aanvaard en in de standaard source code worden overgenomen bespaart dit tevens onderhoudskosten op het desbetreffende onderdeel. Wat is community source? Sakai wordt gepresenteerd als community source, en niet als open source. Het wezenlijke verschil tussen beide concepten is dat in principe bij community source niet individuen de koers grotendeels bepalen, maar de leden van de community. In het geval van Sakai zijn de leden de instellingen voor (hoger) onderwijs en commerciële bedrijven. De Board van de Sakai Foundation weerspiegelt dit ook. Een officiële, juridisch erkende, instantie vergroot de kans op continuïteit voor het produkt Sakai aanzienlijk. Een handzaam artikel over community source en de voordelen ervan, is geschreven door Brad Wheeler (Indiana University, lid van de Sakai Board). Zie http://www.educause.edu/ir/library/pdf/erm0712.pdf .


Pagina 25 van 30

Bijlage 3: Eclipse & Subversion Wat is Eclipse? Eclipse is een open-source framework voor software-ontwikkelomgevingen. Daarnaast is Eclipse ook zelfstandig te gebruiken als krachtige Java-ontwikkelomgeving. Open structuur Eclipse heeft een open structuur waardoor het mogelijk is de functionaliteit uit te breiden door middel van plugins. Dankzij deze plugins kan je in Eclipse niet alleen in Java ontwikkelen, maar tevens in onder andere C, C++, C#, PHP en Perl. Sommige plugins worden gratis aangeboden, anderen, zoals MyEclipse, zijn niet gratis. Commerciële ondersteuning voor Eclipse Eclipse wordt actief ondersteund door IBM, dat zijn eigen producten Websphere Studio Site Developer, Websphere Studio Application Developer, Websphere Studio Enterprise Developer en WebSphere Development Studio Client for iSeries bouwt rondom de Eclipsecode. Daarnaast wordt Eclipse ook door andere commerciele software leveranciers gebruikt, waaronder Active Endpoints, die Eclipse gebruikt als basis van de BPEL procesmodellering tool ActiveBPEL Designer. Meer informatie over Eclipse? Zie Wikipedia: http://nl.wikipedia.org/wiki/Eclipse_(software). Wat is Subversion? Subversion (svn) is een versiebeheersysteem of VCS (Engels: Version Control System). Het is ontworpen als moderne vervanger van CVS (Concurrent Versions System). Waarom Subversion? Een computerprogramma is meestal te complex om in één keer te schrijven. Vaak gaat er enige tijd voorbij voordat het af is (van dagen tot jaren), en zelfs als het af verklaard wordt, gaat de maker vaak verder met een volgende, betere versie van het programma. Een versiebeheersysteem bewaart voldoende informatie om oudere versies te kunnen terugvinden. Ook wordt voor elke wijziging een reden bewaard. Wijzigingen die later problemen blijken te veroorzaken kunnen er gemakkelijk mee ongedaan worden gemaakt. Subversion staat ook toe om verschillende versies van hetzelfde programma tegelijk te beheren. Zo kan de maker zowel aan de nieuwe versie werken als fouten uit de oude versie halen. Hoe werkt Subversion? Subversion maakt gebruik van een centrale repository met een zogenaamd ‘drie dimensionaal filesysteem’, waarbij de toegevoegde derde dimensie de revisies zijn. Gebruikers werken met een lokale kopie van de bestanden in de repository (check-out). Wijzigingen worden in sets terug gestuurd naar de repository (commit), waarbij elke set met wijzigingen een nieuwe versie in de repository wordt. De lokale kopieën worden up-to-date gehouden door regelmatig de wijzigingen van anderen te kopiëren vanuit de repository naar de lokale kopie terug te kopiëren (update). Subversion werkt volgens het “kopiëren - bewerken - samenvoegen” principe. Dit betekent dat meerdere mensen gezamenlijk aan de zelfde bestanden kunnen werken. Niet overlappende wijzigingen van meerdere gebruikers worden bij het terugsturen naar de repository automatisch samengevoegd (merge). Indien de wijziging van twee personen overlappen, worden de wijzigingen geweigerd (conflict) en moet het conflict eerst in de lokale kopie verholpen (resolve) waarna de wijzigingen alsnog naar de repository gestuurd kunnen worden. Tags en branches Door middel van tags kunnen milestones en releases van een project gemarkeerd worden. Met behulp van branches kunnen verschillende versies van een project worden beheerd. De hoofdlijn wordt de trunk genoemd. Een branch is een kopie van de trunk waar ontwikkelaars


Pagina 26 van 30

wijzigingen kunnen aanbrengen zonder de hoofdlijn te beïnvloeden. Branches kunnen bijvoorbeeld gebruikt worden om oudere versies, afgeleide versies of om ontwikkel / test / productie versies van een project te kunnen beheren.

Visualisatie van een simpel Subversion project13

13

Bron: http://en.wikipedia.org/wiki/Image:Subversion_project_visualization.svg


Pagina 27 van 30

Bijlage 4: Spring Framework Wat is het Spring Framework? Het Spring Framework is een ondersteunend raamwerk gericht op ontwikkeling van software binnen het J2EE platform. Het raamwerk combineert een aantal API's en ideeën op een manier die een alternatief biedt voor de standaard manier van het ontwikkelen van software op het J2EE platform .

Kritiek op de ‘normale manier van werken’ met de J2EE standaard Er is veel te veel werk voor nodig om de zakelijke functionaliteit goed in de container te krijgen en dit werk is ook nog eens te ingewikkeld Om transparant te kunnen ontwikkelen, leunt het J2EE-plaftorm heel sterk op configuratie -- instelling van allerlei details middels XML-bestanden. Deze bestanden ("deployment descriptors") zijn vaak erg ingewikkeld van aard, omdat er zeer veel in moet staan. Te ingewikkeld, volgens critici. EJBs zijn ingewikkeld om te ontwikkelen en te zwaar voor wat ze doen Dit is een uitloper van het vorige punt, toegespitst op EJBs. De ontwikkeling van EJBs gaat veel verder dan alleen het definiëren van de zakelijke functionaliteit; om een EJB goed aan te laten sluiten op de container, moet een EJB uitgerust worden met verschillende extra zaken -- niet alleen een deployment descriptor, maar ook minstens twee interfaces. Die synchroon gehouden moeten worden met de EJB als deze verandert. En voor bepaalde soorten EJBs komen daar nog extra interfaces en hulpklassen bij. Een EJB kan een heel kunststuk worden om te ontwikkelen. Veel ingewikkelder dan het ontwikkelen van functionaliteit in "standaard" Java. Daar komt dan nog bij dat EJBs in het gebruik zwaar zijn, door de manier waarop de container ermee omgaat. De container voegt allerlei nuttige functionaliteit toe, maar deze functionaliteit neemt wel geheugen en processortijd in beslag. En voor dienstverlening naar buiten toe ook bandbreedte op het netwerk en databasetijd. Dit laatste kan dusdanig extreme vormen aannemen dat betwijfeld kan worden of EJBs (destijds ontwikkeld als manier om gemakkelijk veilige databasetoegang en dienstverlening op te zetten) wel geschikt zijn als middel om toepassingen te ontwikkelen die zeer databasegericht zijn. De standaard manier om dienstverlening te publiceren is aardig -- maar heeft wel als gevolg dat het gebruiken van diensten de code vastpint op een enkele installatie en ook dat het opvragen van diensten door de hele code heen verspreid wordt Om diensten te kunnen gebruiken binnen J2EE moet de toegang tot die diensten altijd met naam opgevraagd worden. Dit is een repetitieve aangelegenheid die het ook nog eens nodig kan maken om de software die diensten gebruikt hard vast te pinnen aan een bepaalde container-implementatie en -installatie. Transparantie is leuk en aardig, maar houdt op buiten de container; een stuk software van buiten de container dat de diensten van binnen de container wil gebruiken, moet alles hard bij naam en specifiek adres opvragen.

Dependency Injection (of Inversion of Control) Spring probeert de hierboven beschreven problemen te verhelpen door gebruik te maken van het Dependency Injection principe (ook wel Inversion of Control genoemd). De hoofdgedachte achter Spring is dat de container op geen enkele wijze eisen mag stellen aan de implementatie van de zakelijke functionaliteit. De zakelijke functionaliteit dient geïmplementeerd te worden door ‘normale’ Java objecten (in het Engels Plain Old Java Object of POJO genoemd) en dat deze objecten ook niets meer doen dan het implementeren van die functionaliteit. Een POJO mag niet gedwongen worden om een bepaalde vorm aan te nemen om met de container samen te kunnen werken, mag geen extra interfaces of hulpklassen nodig hebben ten behoeve van de container en bij voorkeur ook geen complexe configuratiebestanden.


Pagina 28 van 30

Door van het Dependency Injection principe gebruik te maken kunnen ‘harde’ afhankelijkheden tussen onderlinge componenten voorkomen worden. Afhankelijkheden worden in de objecten ‘geïnjecteerd’ in tegenstelling tot het zelf op zoeken van afhankelijkheden in de EJB werkwijze. De architectuur linkt de componenten, het zijn niet de componenten die elkaar linken. Het resultaat van deze vorm van ‘loose coupling’ is: - een verhoogde modulariteit - minder afhankelijkheid op de container - minder vermenging van zakelijke functionaliteit en code die benodigd is om aan technische randvoorwaarden te kunnen voldoen (en eigenlijk niet gerelateerd is aan de gewenste zakelijke functionaliteit) - objecten die niet in een bepaalde vorm gedwongen zijn door de container - eenvoudig testbare objecten, doordat de afhankelijkheden geïnjecteerd worden kunnen afhankelijkheden eenvoudig vervangen worden met objecten met test data (zogenoemde ‘mock objects’) -

Aspect-georiënteerd programmeren Het Spring framework voorziet in een voorziening voor aspect-georiënteerd programmeren (AOP, of Aspect Oriented Development, AOD). Deze techniek ondersteunt ontwikkelaars in het scheiden van verantwoordelijkheden (concerns), in het bijzonder cross-cutting concerns, om zo modularisatie te bevorderen. Cross-cutting concerns zijn taken door een gehele applicatie verwezen zijn en dus moeilijk in een klasse onder te brengen zijn. Voorbeelden hiervan zijn beveiliging en logging. AOP probeert dit te vereenvoudigen door het mogelijk te maken om een stuk code A "in te lassen" in een ander stuk code B zonder dat B een zichtbare verwijzing heeft naar A.

Model-View-Controller Een andere functionaliteit die Spring biedt, speciaal aan de web-kant van webapplicaties, is een model-view-controller structuur. Deze faciliteit (een alternatief voor zaken als Jakarta Struts) maakt het mogelijk een nette scheiding aan te brengen in de presentatie van informatie via een webpagina en het gebruik van zakelijke functionaliteit achter die webpagina.

Databasetoegang Spring ondersteunt de transparante toegang en het gebruik van allerlei standaard frameworks en APIs, waaronder Hibernate, iBATIS, JDO, JTA en JMS.


Pagina 29 van 30

Bijlage 5: BPEL Modellering met ActiveBPEL Het in hoofdstuk 4 beschreven proces voor het automatisch aanmaken en vullen van een site in Sakai op basis van in VIST ingevoerde vakinformatie wordt voor een belangrijk deel gemodelleerd in een op XML gebaseerde taal die hier speciaal ontworpen is, een zogenaamde Business Process Execution Language (BPEL). Deze taal heeft een voorziening om de web service definitie bestanden (Web Service Definition Language, WSDL) te gebruiken voor het aanspreken van web services en de interacties te beschrijven. Het is niet gebruikelijk om BPEL scripts met een eenvoudige tekstverwerker aan te maken, maar met speciaal hiervoor ontworpen programma’s met een visueel georiënteerd gebruikersinterfave waarmee het procesverloop grafisch weergegeven wordt. Voor de ontwerpen van een deel van het bedrijfsproces in de demoapplicatie is gebruik gemaakt van het BPEL modellerings tool ActiveBPEL van het Amerikaanse bedrijf Active Endpoints14

Procesmodellering met ActiveBPEL Visual Designer De met deze applicatie ontworpen procesbeschrijvingen in BPEL formaat moet worden uitgevoerd door een zogenaamde BPEL execution engine. In ons project is gebruik gemaakt van de gratis Open Source BPEL Engine van Active Endpoints die op een test server onder Tomcat 5.5 draait.

14

Zie: http://www.active-endpoints.com


Pagina 30 van 30

De techniek van Sakai Campus Blend using Sakai

Recommend Documents