Ontwikkeling van een online mediabeheersysteem

Ontwikkeling van een online mediabeheersysteem Ward Lootens

Promotor: prof. dr. ir. Rik Van de Walle Begeleiders: Dieter Van Rijsselbergen, Robbie De Sutter Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

Dankwoord Het schrijven van een thesis is een werk van lange adem. Ik ben dan ook heel dankbaar voor de vele hulp en steun die ik gekregen heb tijdens het schrijven. In het bijzonder zou ik Karel, Robbie en Dieter, de begeleiders van mijn thesis, willen bedanken. Bij hen kon ik steeds terecht met vragen en problemen, of voor het nalezen van bepaalde stukken uit dit boek. Tevens wil ik ook mijn ouders bedanken omdat zij het mogelijk maakten mijn studies en deze thesis tot een goed einde te brengen. Daarnaast bedank ik ook Dries voor het ontlenen van zijn laptop, het heeft mij heel wat tijd frustraties bespaard! Tenslotte wens ik ook nog iedereen te bedanken die zich de moeite heeft getroost om dit werk na te lezen, teneinde het te zuiveren van taal- en tikfouten. Bedankt allemaal!

Ward Lootens, mei 2009

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Ward Lootens, mei 2009

Ontwikkeling van een online mediabeheersysteem door Ward LOOTENS Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2008–2009 Promotor: Prof. Dr. Ir. R. VAN DE WALLE Begeleiders: D. VAN RIJSSELBERGEN, R. DE SUTTER, K. BRAECKMAN Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. J. VAN CAMPENHOUT

Samenvatting In dit werk wordt eerst kort een mediabeheersysteem besproken dat in de praktijk wordt gebruikt binnen een productieomgeving. Het blijkt dat er enkele tekortkomingen zijn met dit systeem, en daarom worden de vereisten opgelijst voor een systeem dat deze tekortkomingen wegwerkt. Vanuit deze vereisten wordt vertrokken om een architectuur uit te werken voor een nieuw mediabeheersysteem met basisfunctionaliteiten. De architectuur wordt in dit werk grondig besproken, samen met enkele belangrijke use cases van het systeem.

Trefwoorden mediabeheer, metadata, grote bestanden uploaden

Development of an online MAM-system Ward Lootens Supervisor(s): Rik Van de Walle, Dieter Van Rijsselbergen, Robbie De Sutter, Karel Braeckman Abstract— This article describes the developement of a core MAM system. An architecture has been built based on the requirements for such a system. Keywords—Media Asset Management, Metadata, Huge File Uploads

N

I. I NTRODUCTION

OWADAYS , more and more television programs are being produced on a file-based manner. This means that no videotapes are used in any of the steps in the production process. It is clear that this results in an ever growing amount of video files in a public broadcaster’s digital archive. The management of all these Media Assets has become a big challenge, in which the use of specialized software plays an important role. The so called Media Asset Management (MAM) systems offer a fully integrated solution for this kind of situations. They provide a user friendly way for adding new items to the system, editing and converting previously added items, and searching the system for available items. Another important functionality of the MAM systems is to provide a way to manage the metadata which is associated with these items. A last important part of a MAM system is a Rights Management System, as most media items are bounded by copyright restrictions. Also the news production of the Vlaamse Radio- en Televisieomroep (VRT), the Flemish public broadcaster, is completely file based since June 2007. The VRT uses Ardome for this production process. Ardome is a MAM system developed by VizRT, which uses a web interface to let the user interact with it. This web interface works correctly, but there are some shortcomings: the interface isn’t very intuitive to use, and cannot be adjusted in a simple way. In this abstract, we will present how we developed a new webbased core MAM system, in which these shortcomings should be eliminated. II. A RCHITECTURE First an overview is given of how the system will be used by the end-users. From this use case, the requirements for the system are deduced. Afterwards, the components used to build the system will be discussed. Finally a scenario in which the user adds an item is described

User

Login

Upload File

Add new Item

Generate Keyframes

Search Item

Generate Low Resolution version

Edit Metadata

Update Item

Fig. 1. Use case

B. Requirements The core MAM system that will be built, must meet the following requirements: • the users must get a rich experience when interacting with the system • the base functionality of a MAM system must be available (add, view, edit and search items, metadata management, media operations) • all of the functionality must be available in one solution, which can be used within an internet browser • the different components of the system should be loosely coupled, so that new components can be integrated without great efforts C. Components An overview of the architecture is shown in figure 2. The system consists of 6 subsystems, which will be described here. Media Management

Upload System

trigger media operations

get file location

add item

A. Use Case When a user is logged in to the system, he is able to add some new files to the system. He can do this by providing some textual info (title, description) about the item, after which he is able to upload a media file. When the file is completely uploaded to the system, some keyframes should be automatically extracted from the video, as well as a low resolution version. Afterwards, the user (or some other user, like an archivist), can provide some additional information about the item, the so called metadata. This metadata can and will be used to make the system searchable, so the users can retrieve the desired material from the archive. In figure 1 a visual representation of this use case is given.

Item Management

describe item

Metadata Management

get user information

User Management

Fig. 2. System architecture

Tools

C.1 User Management Several users interact with the system, and we wish to keep track of some profile information for all these users. Users can register themselves through the User Management component. This component will also allow the user to log in to the system, so they can use the functionalities provided by the other components. C.2 Item Management The central entities in the system, are the media items. These media items are managed by the Item Management component. This component takes care of the adding and editing of media items. Also, the Item Management subsystem is responsible for making the information about these items persistent in the system’s database. C.3 Upload System When a user adds an item to the system, he can upload the media file belonging to that item. The component responsible for this upload and the related tasks, is the Upload System component. As the uploaded files are usual raw and uncompressed video files, the file sizes can become very huge (up to 50 gigabytes and more is not unusual). As a consequence, a standard upload over HTTP won’t be a sufficient solution, because the contemporary internet browsers on 32-bit systems aren’t able to handle uploads of more than 2 gigabytes. Therefore our system makes use of a Java Applet to upload the file to the server. This Applet is signed, so it has access to local files, which it then uploads over FTP to the server. Once the file is completely transferred, the upload system will initiate the automatic extraction of keyframes from the uploaded video, and the generation of a low resolution version of that video.

initiates an significant action, like adding an item, or downloading a video file, this is stored in the database. D. Workflow for adding new item A user can add a new item to the system by providing a title via a form in a webbrowser. When he does so, the new item is created and stored in the database. Based on the itemId of the newly added item, an Applet which will be used to upload the file is configured. This Applet is then send back to the browser, and allows the user to select a local file. The selected file will be uploaded to the FTP server, and when this upload is completed, the Upload System will move the file to the correct location (based on the date and the organisation of the uploader) on the server’s disk. After that, some info (duration, size) about the uploaded video is extracted from the file to be stored in the database. Finally, the Upload System will initiate the generation of keyframes, and also a low resolution version will be generated. This scenario is illustrated in the diagram in figure 3. sd Add new item Item Management

Upload System

User

Media Management

1: send title 2: create item 3: new Item 4: setItemInfo 5: persistItem

6: itemId 7: configure UploadApplet

8: UploadApplet 9: select file

10: upload file to FTP server 11: notify uploaded 12: move file 13: get video info 14: video info 15: update item 16: update DB

loop [every 10 seconds]

C.4 Media Management It is the Media Management component which takes care of the creation of these keyframes and low resolution version. This component will also provide some information about the video files (durarion, size...) which can be stored in the database. In our implemention, all these media operations are perfomed by initiating the appropriate FFmpeg [1] process, but one can easily plug in a component which uses other software for these media operations. C.5 Metadata Management In a production environment, the use of metadata is very important. Not only metadata is the glue between the different stages of the production process, it is also also used by search systems to retrieve the desired items. Our system uses the EBU Core Metadata Set [2] for the modelling of the metadata. We use XMLBeans [3] for the conversion of the EBU Core XML Scheme to Java classes. The Metadata Management Component then uses these classes to automatically generate some HTML input forms, through which the user can provide metadata information describing an item. C.6 Tools The Tools component is responsible for some general functions which are used by the other components. The most important function is the logging of user actions. Each time a user

17: generate keyframe 18: start FFmpeg proces

19: generate low resolution version 20: start FFmpeg proces

Fig. 3. Scenario: add new item

III. C ONCLUSIONS In this paper, an architecture for a new core Media Asset Management system was presented. This system is able to perform all the base functionalities of a MAM system, within one integrated solution which can be used from within an internet browser. The system can be used in the future to experiment with in some smaller projects, as new components can be added without large efforts. R EFERENCES [1] FFmpeg homepage, http://www.ffmpeg.org/ [2] EBU Core Metadata Set, technical report 3293-2008, http://tech.ebu.ch/lang/en/MetadataEbuCore, version 1.0, December 2008 [3] Apache XMLBeans homepage, http://xmlbeans.apache.org, release 2.4.0, July 2008

INHOUDSOPGAVE

vi

Inhoudsopgave Overzicht

ii

Extended abstract

iv

Inhoudsopgave

vi

Lijst van afkortingen

viii

1 Inleiding

1

2 Mediabeheer met Ardome 2.1 Ardome . . . . . . . . . . . . . . . . . . . . 2.2 Webservices aangeboden door Ardome . . . 2.3 Java bibliotheek voor interactie met Ardome 2.4 Ontwikkeling .NET bibliotheek . . . . . . . 2.4.1 Doel . . . . . . . . . . . . . . . . . . 2.4.2 Voorverwerkingsstap . . . . . . . . . 2.4.3 Authenticatie . . . . . . . . . . . . . 2.4.4 Resultaat . . . . . . . . . . . . . . .

. . . . . . . .

3 3 4 5 6 6 7 9 10

3 Ontwikkeling van nieuw mediabeheersysteem 3.1 Tekortkomingen van Ardome . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Vereisten voor nieuw systeem . . . . . . . . . . . . . . . . . . . . . . .

12 12 12

4 Rijke internettoepassingen 4.1 Inleiding . . . . . . . . . . . 4.2 Technologieën . . . . . . . . 4.2.1 Ajax . . . . . . . . . 4.2.2 Adobe Flex . . . . . 4.2.3 Microsoft Silverlight 4.2.4 Andere . . . . . . . . 4.3 Besluit . . . . . . . . . . . .

. . . . . . .

14 14 15 15 19 21 22 23

5 Systeemarchitectuur 5.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Ingest procedure . . . . . . . . . . . . . . . . . . . . . . . . . .

26 26 26

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

INHOUDSOPGAVE

5.2

5.3

vii

5.1.2 Gebruik van metadata . . . . . . . . . Componenten . . . . . . . . . . . . . . . . . . 5.2.1 Gebruikersbeheer . . . . . . . . . . . . 5.2.2 Itembeheer . . . . . . . . . . . . . . . 5.2.3 Uploadsysteem . . . . . . . . . . . . . 5.2.4 Mediabeheer . . . . . . . . . . . . . . 5.2.5 Metadatabeheer . . . . . . . . . . . . . 5.2.6 Tools . . . . . . . . . . . . . . . . . . . Interactie van de componenten . . . . . . . . . 5.3.1 Scenario: gebruikersbeheer . . . . . . . 5.3.2 Scenario: doorzoeken van het systeem . 5.3.3 Scenario: aanpassen van metadata . .

6 Ingest workflow 6.1 Upload . . . . . . . . . . . . . . . . . . . . . 6.1.1 Versie 1: HTTP Upload . . . . . . . 6.1.2 Alternatieven voor HTTP upload . . 6.1.3 Finale versie: FTP upload via Applet 6.2 Media operaties . . . . . . . . . . . . . . . . 6.2.1 Keyframe-extractie . . . . . . . . . . 6.2.2 Generatie van een lageresolutieversie

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

7 Metadatabeheer 7.1 Metadatamodel . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 EBU Core . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Opslag van de metadata . . . . . . . . . . . . . . . 7.2 Interactie van de gebruiker met de metadata . . . . . . . . 7.2.1 Doorzoeken van het systeem op basis van metadata 7.2.2 Toevoegen, bewerken en verwijderen van metadata 8 Gebruikersinterface 8.1 Registratie . . . . . . . . . . 8.2 Aanmelden bij het systeem . 8.3 Nieuw item toevoegen . . . 8.4 Doorzoeken van het systeem 8.5 Detailoverzicht van item . . 8.6 Bewerken van metadata . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

27 27 29 30 31 31 33 33 35 35 36 36

. . . . . . .

39 39 39 44 47 51 51 51

. . . . . .

54 54 55 55 57 57 58

. . . . . .

64 64 64 66 66 68 68

9 Besluit

72

A Technologiekeuzes A.1 Webserver . . . . . A.2 FTP-server . . . . A.3 Gebruikersinterface A.3.1 Webpagina’s A.3.2 Videospeler

74 74 75 75 75 75

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

INHOUDSOPGAVE

viii

A.4 Databank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Media operaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B EBU Core specificatie B.1 Title . . . . . . . . . B.2 Creator . . . . . . . B.3 Subject . . . . . . . B.4 Description . . . . . B.5 Publisher . . . . . . B.6 Contributor . . . . . B.7 Date . . . . . . . . . B.8 Type . . . . . . . . . B.9 Format . . . . . . . . B.10 Identifier . . . . . . . B.11 Source . . . . . . . . B.12 Language . . . . . . B.13 Relation . . . . . . . B.14 Coverage . . . . . . . B.15 Rights . . . . . . . . B.16 Version . . . . . . . . B.17 Publication History . B.18 Metada provider . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

C Code C.1 Inhoud cd . . . . . . . . . . . . . . . . . C.1.1 WSDLConvert . . . . . . . . . . C.1.2 CoreMAM.war . . . . . . . . . . C.1.3 UploadApplet.jar . . . . . . . . . C.1.4 CoreMAMDatabaseStructure.sql C.1.5 LowResPlayer.zip . . . . . . . . . C.2 Installatie . . . . . . . . . . . . . . . . . C.2.1 Precondities . . . . . . . . . . . . C.2.2 Installeren op Tomcat-server . . . Bibliografie

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . .

76 76

. . . . . . . . . . . . . . . . . .

78 78 78 78 78 79 79 79 79 79 79 79 79 80 80 80 80 80 80

. . . . . . . . .

81 81 81 81 82 82 82 82 82 83 84

INHOUDSOPGAVE

Lijst van afkortingen AIR

Adobe Integrated Runtime

AJAX

Asynchronous JavaScript and XML

AMF

Adobe Action Message Format

API

Application Programming Interface

CORBA

Common Object Request Broker Architecture

CSS

Cascading Style Sheets

DOM

Document Object Model

EBU

European Broadcasting Union

FLV

Flash Video

FTP

File Transfer Protocol

GWT

Google Web Toolkit

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transfer Protocol Secure

IP

Internet Protocol

JAR

Java Archive

JAXP

Java API for XML Processing

JDK

Java Developement Kit

JRE

Java Runtime Environment

ix

INHOUDSOPGAVE JSON

JavaScript Object Notation

JSP

JavaServer Pages

MAM

Media Asset Management

MIME

Multipurpose Internet Mail Extenstions

RIA

Rijke Internet Applicatie

SMTP

Simple Mail Transfer Protocol

SOAP

Simple Object Access Protocol

URL

Uniform Resource Locator

VRT

Vlaamse Radio- en Televisieomproep

WAR

Web application Archive

WSDL

Web Services Description Language

XAML

Extensible Application Markup Language

XML

Extensible Markup Language

XSD

XML Schema Definition

XSLT

Extensible Stylesheet Language Transformation

x

1

Hoofdstuk 1 Inleiding Tegenwoordig worden steeds meer televisieprogramma’s geproduceerd op een volledig bestandsgebaseerde wijze. Dit wil zeggen dat men in geen enkele stap van het productieproces nog gebruik maakt van videobanden. Zowel het opnemen van de beelden, het uitwisselen en monteren ervan en het uitzenden van de afgewerkte programma’s gebeurt volledig via bestanden. Het is duidelijk dat hierdoor een erg grote hoeveelheid aan mediabestanden ontstaat. Het beheren van al deze Media Assets is doorgaans een grote uitdaging op gebied van informatietechnologie (IT). Het is dan ook aangewezen hiervoor geoptimaliseerde software te gebruiken, met name de Media Asset Management (MAM) systemen (mediabeheersystemen). Mediabeheersystemen maken het mogelijk om op eenvoudige wijze nieuwe media toe te voegen aan het systeem en om mediabestanden te bewerken en monteren. Ook het transcoderen van videobestanden naar verschillende bestandsformaten is een belangrijke functie. Het allerbelangrijkste is misschien wel de mogelijkheid om metadata toe te voegen aan de mediabestanden in het systeem en die metadata aan te passen zodat ze up to date blijft. Deze metadata is namelijk onontbeerlijk wil men in staat zijn om op een efficiënte manier de mediabestanden te doorzoeken. Men heeft namelijk weinig aan een systeem dat wel grote hoeveelheden bestanden kan bijhouden, als men niet in staat is deze bestanden later terug te vinden. Aangezien er op de meeste mediabestanden auteursrechten rusten, is het ook belangrijk dat men deze rechten op een efficiënte en correcte manier kan beheren. Een Rights Management System is dus een onmisbaar onderdeel van een mediabeheersysteem. Ook bij de Vlaamse Radio- en Televisieomroep (VRT) is de volledige nieuwsproductie sinds juni 2007 volledig bestandsgebaseerd. Voor het mediabeheer maakt men daar gebruik van het Ardome-mediabeheersysteem. Dit systeem gebruikt een webinterface waarmee gebruikers items kunnen terugvinden, bekijken, monteren, etc. Deze web-

2 interface werkt naar behoren, maar er zijn toch enkele tekortkomingen. De gebruikersinterface is bijvoorbeeld niet eenvoudig aan te passen, en is bovendien niet erg intu¨ıtief. Het doel van deze thesis is dan ook om te onderzoeken op welke manier een webgebaseerd mediabeheersysteem met basisfunctionaliteiten kan ontwikkeld worden dat deze tekortkomingen wegwerkt, en om dan ook effectief een dergelijk systeem te implementeren. In hoofdstuk 2 wordt een overzicht gegeven van de verschillende manieren waarop men met Ardome kan interageren. In hoofdstuk 3 worden enkele tekortkomingen van Ardome toegelicht, en worden de vereisten beschreven van het systeem dat zal ontwikkeld worden om deze tekortkomingen weg te werken. Het is de bedoeling dat dit systeem gebruiksvriendelijk is, en de gebruiker een rijke gebruikerservaring bezorgt. In hoofdstuk 4 wordt dieper ingegaan op wat dit precies betekent, en er wordt eveneens een overzicht gegeven van de technologieën die men kan gebruiken om een dergelijke Rijke Internet Applitcatie te ontwikkelen. In hoofdstuk 5 wordt op basis van de vereisten een architectuur uitgewerkt voor het systeem. In hoofdstuk 6 en 7 worden dan de twee belangrijkste gebruikersscenario’s verder uitgewerkt, namelijk de ingest procedure (het toevoegen van een nieuw item) en het bewerken van de metadata. In hoofdstuk 8 tenslotte wordt een overzicht gegeven van de gebruikersinterface die de gebruiker uiteindelijk te zien krijgt.

3

Hoofdstuk 2 Mediabeheer met Ardome 2.1

Ardome

Net zoals bij vele andere televisieomroepen, is ook bij de VRT de nieuwsproductie sinds kort volledig bestandsgebaseerd. Men maakt voor het beheren van die mediabestanden gebruikt van het Ardome-systeem. Deze software wordt geleverd door het Zweedse bedrijf Ardendo, dat sinds een tweetaal jaar in handen is van het VizRT, een Noors softwarebedrijf dat een grote waaier van softwareoplossingen aanbiedt voor televisiestations. Via een webinterface kunnen gebruikers mediabestanden terugvinden, bekijken (previews), monteren, metadata aanpassen, exporteren enzovoort. Voor het inbrengen van nieuwe items in het systeem, het ingest-proces, gebruikt de VRT een softwareoplossing van OpenCube Technologies [1]. Deze oplossing bundelt het downloaden van de videobestanden van een camera, het transcoderen ervan naar het juiste formaat en de FTP-streaming naar het Ardome-systeem in één enkel proces. Ook de on-the-field-metadata, de metadata die onmiddellijk wordt toegevoegd tijdens de opnames (bijvoorbeeld informatie over de exacte locatie van opnames), wordt tijdens dit proces gelinkt aan het item in het Ardome-systeem. Op deze manier kunnen journalisten die terugkeren van een reportage er met één actie voor zorgen dat de items in het Ardome-systeem terechtkomen, waar ze dan onmiddellijk beschikbaar zijn, om bijvoorbeeld een eerste montage te maken. Binnen het VRT-Medialab, de onderzoeksafdeling van de VRT voor wat betreft digtale mediaproductie, beschikt men ook over een versie van Ardome. Deze versie van Ardome gebruikt men voor onderzoeksdoeleinden of om bepaalde nieuwe zaken te testen. Zo werd er bovenop de bestaande mediadatabank van Ardome een nieuw zoeksysteem ontwikkeld, onder de naam Trouvaille [2]. Het is ook met deze versie van Ardome dat in het kader van dit eindwerk zal gewerkt worden, en dus niet met het

2.2. WEBSERVICES AANGEBODEN DOOR ARDOME

4

systeem dat in werkelijkheid gebruikt wordt voor de nieuwsproductie binnen de VRT.

2.2

Webservices aangeboden door Ardome

Naast de traditionele manier van werken met Ardome (via de online gebruikersinterface) kan men ook met Ardome interageren als een extern systeem. Dit is mogelijk door gebruik te maken van de publieke SOAP-webservices die Ardome voorziet. Deze webservices worden beschreven aan de hand van verschillende WSDL-bestanden. WSDL (Web Services Description Language) is een XML-formaat (Extensible Markup Language) dat gebruikt wordt om de interfaces van een webservice te beschrijven. Een WSDL-beschrijving bestaat uit een reeks van definities. Volgende belangrijke elementen worden gedefiniëerd [3]: types De datatypes die gebruikt worden door de webservice. Deze datatypes kunnen eenvoudige XML-datatypes zijn (String, Date, numerieke types...) maar het kunnen evengoed complexere types zijn. In het laatste geval verwijst men in het WSDL-bestand naar een XSD-bestand (XML Schema) waarin die complexe types gedefinieerd worden. message De boodschappen die de webservice gebruikt. Een boodschap bestaat uit verschillende logische delen, die elk geassocieerd zijn met een bepaald datatype. binding Hier definieert men het communicatieprotocol dat wordt gebruikt door de webservice. Ondere andere SOAP, HTTP en MIME kunnen hiervoor gebruikt worden. portType Dit zijn de methodes die men kan uitvoeren met de webservice. Iedere methode verwijst naar een input message en output messages. port Hiermee specifieert men een adres voor de binding, waardoor een communicatieeindpunt gecreëerd wordt. service Dit is een verzameling van met elkaar verwante eindpunten. De service kan gezien worden als een container voor de methodes die beschikbaar zijn via de gedefinieerde communicatieprotocollen. Wanneer men dus beschikt over een WSDL-bestand horende bij een webservice, kan men afleiden welke methodes de webservice aanbiedt, welke parameters die methodes verwachten, en wat het datatype van het resultaat van de methode is.

2.3. JAVA BIBLIOTHEEK VOOR INTERACTIE MET ARDOME

5

Ardome gebruikt SOAP als communicatieprotocol voor zijn webservices. SOAP (Simple Object Access Protocol) is een protocol waarmee men de communicatie tussen verschillende entiteiten kan verzorgen [4]. SOAP verstuurt boodschappen in XMLformaat, meestal over HTTP (HyperText Transfer Protocol), maar ook HTTPS (HyperText Transfer Protocol Secure), SMTP (Simple Mail Transfer Protocol) en FTP (File Transfer Protocol) zijn mogelijke transportprotocollen. Het grote voordeel van het gebruik van XML-boodschappen is dat deze ook leesbaar zijn voor personen, en niet alleen voor computers. Een nadeel is dat de boodschappen omvangrijker zijn dan binaire boodschappen (die bijvoorbeeld bij CORBA (Common Object Request Broker Architecture) [5] gebruikt worden), wat de verwerkingssnelheid negatief kan be¨ınvloeden. De voornaamste API’s (SOAP-webservices) die Ardome aanbiedt zijn: Public API Via de Public API heeft men toegang tot de publieke functies die kunnen aangeroepen worden zonder geauthenticeerd te zijn door Ardome. In de praktijk is er slechts één methode die kan aangeroepen worden, en dat is de login methode. Hiermee kan de gebruiker zich aanmelden bij het Ardome-systeem, zodat hij in staat is om functies van andere API’s aan te roepen waarvoor wel authenticatie vereist is. Data Model API Deze API wordt gebruikt om toegang te krijgen tot de data die het Ardome-systeem beheert. Men kan alle beschikbare informatie opvragen over de verschillende media-items, over programma’s, over metadata die bij een bepaald item hoort... Het is ook mogelijk om bestaande data aan te passen, of nieuwe data toe te voegen aan het systeem. Media API Via de Media API kan men allerlei acties uitvoeren op mediabestanden aanwezig in het systeem. Men kan een mediabestand bijvoorbeeld transfereren naar een andere locatie, transcoderen naar een ander formaat of verwijderen uit het systeem. Info API Met deze API kan men info verkrijgen over alle services die beschikbaar zijn. Met de search-methode kan men ook de Ardome-databank doorzoeken.

2.3

Java bibliotheek voor interactie met Ardome

Uit de WSDL-bestanden kan men afleiden welke SOAP-boodschappen men moet gebruiken om te interageren met Ardome, en ook hoe men de ontvangen SOAP-berichten

2.4. ONTWIKKELING .NET BIBLIOTHEEK

6

moet verwerken. Het zou echter te omslachtig zijn om iedere keer zelf de code te schrijven die instaat voor de SOAP-communicatie, en daarom werd er door VizRT, de makers van Ardome, reeds een Java-bibliotheek ontwikkeld die daarvan abstractie maakt. Door gebruik te maken van die bibliotheek is het mogelijk om in eender welk Java-programma te interageren met Ardome, zonder dat men daarvoor zelf één letter SOAP moet schrijven. Deze bibliotheek is opgebouwd door gebruik te maken van WSDL2Java, een tool binnen Apache Axis, een SOAP-framework [6]. Met WSDL2Java is het mogelijk om op basis van WSDL-informatie Java-objecten te genereren. Die Java-objecten bieden dezelfde functionaliteit aan als de webservices die door de WSDL-bestanden beschreven worden. Die objecten kunnen vervolgens gebruikt worden zoals eender welk ander Java-object. De communicatie met de webservices zal volledig “onder de motorkap” gebeuren, zodanig dat de gebruiker niet eens hoeft te weten dat hij met externe objecten werkt. Wanneer men zich bijvoorbeeld wenst aan te melden bij Ardome kan dit gebeuren met de volgende code: PublicAPI publicAPI = new PublicAPI(SOAPserver); String sessionID = publicAPI.login(username, password, application, version); Het sessionId dat men op deze manier ontvangt, dient men te gebruiken bij iedere oproep van een methode die niet tot de Public API behoort. Men kan bijvoorbeeld een Item uit Ardome opvragen op deze manier: DataModelAPI dataModelAPI = new DataModelAPI(SOAPserver, username, sessionId); Item item = dataModelAPI.getItemById("1100080312087890821");

2.4 2.4.1

Ontwikkeling .NET bibliotheek Doel

Het is duidelijk dat de interactie met Ardome op deze manier erg eenvoudig wordt. Er is echter enkel een dergelijke bibliotheek beschikbaar voor Java. Wanneer men een andere programmeertaal gebruikt, zal men nog steeds zelf moeten instaan voor de SOAP-communicatie met Ardome. Het eerste deel van dit eindwerk bestond er dan ook in een gelijkaardige bibliotheek te ontwikkelen voor het .NET-Framework van Microsoft. De bibliotheek (Class Library) werd geschreven in C#, één van de belangrijkste talen van .NET. In het .NET-Framework zorgt de tool Web Services Description Language Tool


7

(wsdl.exe) van Microsoft ervoor dat er automatisch code wordt gegenereerd voor de interactie met de webservice. De functionaliteit van wsdl.exe is dus gelijkaardig aan die van WSDL2Java, namelijk het aanmaken van proxy-objecten die de SOAP-communicatie verborgen houden voor de programmeur. Nu men over de proxies beschikt, volstaat het om de code te schrijven die de proxies op de correcte manier aanspreekt om te kunnen interageren met Ardome.

2.4.2

Voorverwerkingsstap

Probleemstelling Het genereren van de code voor de Public API verloopt zonder problemen. Alle benodigde proxies worden zonder problemen gegenereerd, en kunnen ook zonder problemen gebruikt worden om zich aan te melden bij Ardome en aldus een sessiesleutel te verkrijgen. Bij het importeren van de WSDL-code voor de andere API’s loopt het echter mis: de WSDL tool is niet in staat om de webservice te importeren. De oorzaak blijkt te liggen bij het feit dat de tool de definities van bepaalde datatypes niet vindt. Deze dataypes zijn nochtans correct gedefinieerd in een extern schema, en dat schema wordt correct ge¨ımporteerd in het WSDL-document via een import statement: <xsd:import namespace="ARDOME/SCHEMAS/complextype" schemaLocation="../../schemas/complextype.xsd" /> <xsd:import namespace="ARDOME/SCHEMAS/metadata" schemaLocation="../../schemas/metadata.xsd" /> Het probleem blijkt echter te zijn dat de externe schema’s op hun beurt ook nog refereren naar andere externe schema’s. In metadata.xsd bijvoorbeeld is volgende regel te vinden: Ook in metadatacont.xsd worden nog een hele reeks externe schema’s ge¨ıncludeerd. Het blijkt dus dat de WSDL-tool niet overweg kan met dit herhaaldelijk includeren van externe bestanden. Bij het importeren van de Public API stelt dit probleem zich niet, aangezien daar enkel eenvoudige datatypes worden gebruikt en er bijgevolg geen import van externe schema’s aan te pas dient te komen. Na wat opzoekingswerk blijkt dat dit een gekend probleem is, dat door Microsoft officieel erkend is als bug [7]: “(...) However, if the WSDL document uses a schema that is defined in an external XML Schema (.xsd file) that uses an include element () to obtain type information, you may receive the following error message (...)”


8

Er is tot op heden geen nieuwere versie van de WSDL-tool beschikbaar waarbij dit probleem opgelost is. Om toch gebruik te kunnen maken van de webservice binnen het .NETFramework moet er dus een andere manier gevonden worden om rondom dit probleem te werken.

Aangezien het probleem ligt bij de aanwezigheid van verschillende include-

statements, ligt het voor de hand ervoor te zorgen dat er geen dergelijke statements meer aanwezig zijn. Het doel is dus om in alle bestanden de include-statements te vervangen door de eigenlijke inhoud van de files waarnaar verwezen wordt. Wegens de grote hoeveelheid include-statements (meer dan 100) zou het tijdrovend zijn om al deze vervangingen manueel te doen. Bovendien zou al dat werk opnieuw moeten gebeuren wanneer één van de ge¨ıncludeerde bestanden aangepast zou worden.

WSDLConvert Daarom heb ik besloten een programma te ontwikkelen dat deze vervangingen automatisch uitvoert. Op die manier kan men het programma gebruiken als een soort voorverwerking, vlak voor men de webservice effectief wil importeren. Zo is men zeker dat men steeds met de recentste beschrijving van de webservice werkt. Het ontwikkelde programma kreeg de naam WSDLConvert. WSDLConvert is uit te voeren via de commandolijn, en verwacht 2 parameters. De eerste parameter is een URL die verwijst naar de locatie van het WSDL-document dat verwerkt dient te worden. Als tweede parameter kan men een locatie opgeven waar men het outputbestand wenst op te slaan. Het outputbestand is één groot WSDL-document waarin alle gebruikte datatypes in het document zelf zijn opgenomen. Het outputbestand bevat dus geen include- of import-statements meer. Men kan nu het outputbestand gebruiken als input voor wsdl.exe, dat dan op correcte wijze de gewenste proxy objecten zal genereren. Het algoritme waarmee alle include- en import-statements vervangen worden is het volgende: 1. Selecteer de eerste node in het document die van het type import of include is 2. Leid de locatie van het externe bestand af uit het schemaLocation attribuut 3. Lees het externe bestand in 4. Vervang alle relatieve urls in het externe bestand door absolute urls (op die manier worden bestanden waarnaar verwezen wordt ook teruggevonden bij lokaal gebruik) 5. Vervang de beschouwde import of include node door de inhoud van het externe bestand 6. Herhaal stap 1 tot 5 zolang er nog een import of include node aanwezig is Momenteel dient WSDLConvert uitgevoerd te worden op de computer van de ontwikkelaar die .NET-software wil schrijven die gebruikt maakt van de Ardome API’s (Figuur 2.1). De


9

gebruiker zal dan een nieuwe Web Reference moeten aanmaken die verwijst naar het lokaal gegenereerde document, en dus niet naar een bestand op de server.

Conversie op server Het zou misschien interessanter zijn indien de voorverwerkingsstap met WSDLConvert zou kunnen uitgevoerd worden op de server, iedere keer als iemand een aanvraag doet naar het betreffende WSDL-document. Op die manier blijft alles transparant voor de .NET-ontwikkelaar doordat die een Web Reference kan aanmaken die verwijst naar een WSDL-document op de server, zonder zelf nog een extra stap te moeten ondernemen om het document te verwerken. Een manier om dit te verwezenlijken zou kunnen zijn om op de server een Java Servlet te laten draaien die instaat voor de conversie. Die Servlet zou dan alle requests voor “problematische” WSDL-documenten kunnen onderscheppen, de conversie van het originele bestand uitvoeren, en de request beantwoorden met het zopas gegenereerde bestand, dat dan zonder problemen kan verwerkt worden door wsdl.exe .

2.4.3

Authenticatie

Zoals vermeld is voor de meeste API’s authenticatie ten opzichte van Ardome vereist. Men kan zich via de login-methode uit de Public API aanmelden bij het systeem door middel van een gebruikersnaam en wachtwoord. Als resultaat hiervan bekomt men een sessiesleutel die 24 uur geldig blijft. Die sessiesleutel dient men te gebruiken bij het aanspreken van de API’s waarvoor Authenticatie vereist is. Dit is onder andere het geval bij de Data Model API. De sessiesleutel dient bij iedere SOAP-aanvraag mee te worden verstuurd in de vorm van een cookie met de naam ARDSOAPSESSID. De waarde van de cookie moet van de volgende vorm zijn: <username>:<sessionID>

In de ontwikkelde Class Library werd de authenticatie op deze manier bekomen:

t^> ĚŽĐƵŵĞŶƚ

t^>ŽŶǀĞƌƚ͘ĞǆĞ

ƉƌŽĐĞƐƐĞĚ t^> ĚŽĐƵŵĞŶƚ

ǁƐĚů͘ĞǆĞ

ƐŽƵƌĐĞ ĐŽĚĞĨŽƌ ηƉƌŽǆŝĞƐ

Figuur 2.1: Voorverwerken van WSDL documenten met behulp van WSDLConvert


10

dataModelAPI = new DataModelAPIService(); CookieContainer cc = new CookieContainer(); cc.Add(new Cookie("ARDSOAPSESSID", username + ":" + sessionId)); dataModelAPI.CookieContainer = cc;

Hierbij is DataModelAPIService de door wsdl.exe gegenereerde proxy. Door een CookieContainer, een object uit het .NET Framework, die de gepaste cookie bevat toe te kennen aan de gebruikte instantie van DataModelAPIService zal iedere gegenereerde SOAP-aanvraag de cookie bevatten, en dus toegelaten worden door Ardome.

2.4.4

Resultaat

Wanneer eenvoudige functies van de ontwikkelde bibliotheek getest worden, blijkt alles naar behoren te werken. Er kan succesvol een sessiesleutel verkregen worden, die vervolgens kan gebruikt worden om eenvoudige informatie op te vragen aan Ardome. Het uitvoeren van dit codefragment PublicAPI publicApi = new PublicAPI(SOAPserver); String sessionID = publicApi.login(username, password, application, version); Console.WriteLine("SessionID: " + sessionID); DataModelAPI dataModelApi = new DataModelAPI(SOAPserver, username,sessionID); Item item = dataModelApi.getItemById("1100080312087890821"); Console.WriteLine("Title: " + item.itm_title); levert bijvoorbeeld de volgende uitvoer op: Session ID: NIvmMnNw5qrZe6MQKG6bJyKh6Crt6HQZ Title: intro_antarctica Wanneer echter meer complexe informatie, zoals de metadata horende bij een element, wordt opgevraagd, blijkt dit niet te lukken. Bij het aanroepen van de getMetadata-methode van het DataModelAPI-object, wordt effectief een Metadata-object verkregen als resultaat, maar alle waarden van dit object blijken null te zijn. Aanvakelijk wordt dit niet gezien als een fout, aangezien er van wordt uit gegaan dat er eenvoudigweg geen metadata beschikbaar is voor dit item. Pas later blijkt dat dit wel het geval was, en dat er dus blijkbaar ergens een fout optreedt tijdens de uitvoering. Aangezien debuggen van de Class Library geen oorzaak van het probleem blootlegt, wordt het netwerkverkeer bestudeerd tijdens de uitvoer van het testprogramma. Daaruit blijkt dat alle SOAP-aanvragen correct worden verstuurd naar Ardome, en dat ze bovendien ook correct worden beantwoord. Ten gevolge van de


11

getMetadata-aanvraag wordt er wel degelijk een SOAP-envelope die het gewenste Metadataobject bevat, teruggestuurd door Ardome. Alle metadata-informatie die beschikbaar is, is duidelijk te lezen in XML-formaat in de netwerklogs. Het probleem zit dus duidelijk niet in de SOAP-communicatie tussen de client en de server. Blijkbaar moet er dus iets fout gaan bij de deserialisatie van de SOAP-data tot .NET-objecten. Tot op heden is niet exact gevonden waar die fout zich voordoet, aangezien de door wsdl.exe gegenereerde proxies moeilijk te debuggen zijn. Er is niet dieper ingegaan op dit gebrek, aangezien de prioriteit kwam te liggen bij de ontwikkeling van het uiteindelijke mediabeheersysteem. De .NET-bibliotheek functioneert dus nog niet volledig, en verder onderzoek naar de oorzaak blijft nog te verrichten.

12

Hoofdstuk 3 Ontwikkeling van nieuw mediabeheersysteem 3.1

Tekortkomingen van Ardome

De oorspronkelijke doelstelling van deze masterproef was om bovenop het bestaande Ardomesysteem, een nieuwe webinterface te bouwen. Bij de huidige webinterface treden namelijk enkele tekortkomingen op. Het grootste probleem van de bestaande webinterface, is dat die niet eenvoudig en snel aan te passen is aan de individuele noden en wensen van de gebruikers. Daarnaast is de gebruikersinterface ook niet erg intu¨ıtief. Er zijn te veel muisklikken nodig om uiteindelijk tot een weergave van de video te komen. Om die video te kunnen afspelen moet die bovendien eerst gedownload worden, om dan met behulp van externe software afgespeeld te worden. Ook het overzicht van de zoekresultaten is dikwijls onduidelijk, wat niet bevorderlijk is om snel bij het gezochte item uit te komen. Het doel van de vernieuwde webinterface zou dan zijn om de huidige tekortkomingen van Ardome op te lossen. Een bijkomend probleem met Ardome is dat men binnen onderzoeksprojecten te vaak bezig is met workarounds voor de bestaande problemen in Ardome. Zo werd bijvoorbeeld een eigen webservice ontwikkeld die instaat voor de generatie van keyframes voor de mediabestanden in Ardome, aangezien de keyframegeneratie binnen Ardome zelf niet volstaat.

3.2

Vereisten voor nieuw systeem

Gezien de hierboven aangehaalde problemen zou het handig zijn om te beschikken over een eigen core-MAM-systeem dat eenvoudig uitbreidbaar en aanpasbaar is. Dit systeem zou in de toekomst gebruikt kunnen worden voor onderzoeks- en testdoeleinden binnen enkele kleinere projecten. Vlak voor kerstmis is dan ook in samenspraak met het VRT-Medialab beslist om niet voort te bouwen op het bestaande Ardome-systeem, maar om een volledig nieuw systeem

3.2. VEREISTEN VOOR NIEUW SYSTEEM

13

te creëren. Het systeem moet aan de volgende vereisten voldoen: • Het systeem moet intu¨ıtief zijn in gebruik, de gebruiker moet een rijke ervaring krijgen wanneer hij interageert met het systeem. • De basisfunctionaliteiten van een mediabeheersysteem moeten voorzien zijn: – toevoegen van nieuwe items – toegevoegde items overzichtelijk weergeven (inclusief een preview van de video als die beschikbaar is) – bewerkingen uitvoeren op de mediabestanden (keyframes genereren, transcoderen tussen verschillende formaten...) – doorzoeken van het systeem – beheren van metadata horende bij de items • Dit alles moet kunnen gebeuren binnen één enkele ge¨ıntegreerde oplossing die men kan gebruiken via een webbrowser. • Het systeem moet zoveel mogelijk modulair zijn opgebouwd, zodanig dat men eenvoudig nieuwe componenten kan invoegen, of bestaande componenten kan vervangen. In hoofdstuk 4 zal besproken worden op welke manieren men een rijke internettoepassing kan ontwikkelen. In hoofdstuk 5 wordt vervolgens een architectuur voor het systeem uitgewerkt die in staat moet zijn om aan de vereisten te voldoen.

14

Hoofdstuk 4 Rijke internettoepassingen 4.1

Inleiding

Rijke Internet Applicaties (RIA’s) zijn webtoepassingen die bepaalde eigenschappen en functionaliteiten van traditionele desktoptoepassingen hebben. Een belangrijk aspect hierbij is de verbeterde gebruikerservaring die bekomen wordt door een grotere interactiviteit ten opzichte van traditionele webtoepassingen. De term RIA werd voor het eerst gebruikt door Macromedia [8] toen die wezen op de toenmalige limieten van rijkheid van gebruikersinterfaces die kon bereikt worden met standaard webtechnieken zoals HyperText Markup Language (HTML) en Cascading Style Sheets (CSS). Voor het gebruik van RIA’s is het voldoende dat men beschikt over een internetbrowser, indien nodig uitgerust met de nodige plugins. Men zegt dat die applicaties draaien binnen een sandbox, wat wil zeggen dat ze beperkte rechten hebben ten aanzien van de lokale systeemmiddelen. Dit maakt dat RIA’s bepaalde beperkingen hebben ten opzichte van traditionele desktop-toepassingen, zoals bijvoorbeeld een verminderde toegang tot het lokale bestandssysteem. Een groot voordeel van RIA’s is dat ze weinig extra last met zich meebrengen: er is geen lokale installatie vereist, aangezien de toepassing volledig in de webbrowser draait. Er moeten dus ook geen updates worden gedownload en ge¨ınstalleerd, omdat de wijzigingen gebeuren op de webserver. Daartegenover staat wel dat sommige RIA’s de installatie van een plugin vereisen. De meeste applicaties zullen ervoor zorgen dat de installatie van de gewenste plugin zo eenvoudig mogelijk kan gebeuren, zodat er zo weinig mogelijk overlast is voor de gebruiker. RIA’s reageren doorgaans sneller op acties van de gebruiker dan traditionele webtoepassingen, daarvoor zijn ze trouwens ook ontworpen. Dit komt doordat slechts het gewijzigde deel van de informatie van de webserver moet worden gehaald, in plaats van alle data. Hierdoor is er idealiter minder dataverkeer tussen de client en de webserver. In de praktijk blijkt dit echter niet altijd het geval te zijn, aangezien er dikwijls meer asynchroon verkeer nodig

¨ 4.2. TECHNOLOGIEEN

15

is om de rijkere ervaring te bewerkstelligen. Over het algemeen zal men bij RIA’s meer functionaliteit naar de client-zijde overhevelen in vergelijking met traditionele webtoepassingen. Daar waar bij traditionele webtoepassingen het weergeven van de verkregen objecten zowat de enige activiteit was die moest worden uitgevoerd door de webbrowser, zal de RIA nu ook een aanzienlijk deel van de presentatie-logica uitvoeren aan de client-zijde. Vaak zal er namelijk enkel data ontvangen worden van de server, en dan is het aan de browser (of externe plugin) om te beslissen op welke manier die data wordt weergeven. Doorgaans kan er ook een groot deel van de “business”-logica op de client worden uitgevoerd. Voorbeelden hiervan zijn het uitvoeren van eenvoudige berekeningen, of het (gedeeltelijk) valideren van invulformulieren. Het grootste deel van de programmalogica zal echter nog steeds aan de serverzijde worden uitgevoerd, net als de interactie met externe databronnen, en dit in tegenstelling tot tradionele desktoptoepassingen. Dit toont aan dat de RIA’s zich eigenlijk bevinden in de overgangszone tussen desktoptoepassingen en traditionele webapplicaties [9].

4.2

Technologie¨ en

In het kader van dit werk werden enkele veelgebruikte technologiën voor de ontwikkeling van RIA’s bestudeerd.

4.2.1

Ajax

Ajax staat voor Asynchronous JavaScript and XML. Het is een samenvattende term die verschillende technologiën overkoepelt. Volgende technologiën worden gebruikt [10]: • XHTML en CSS voor de presentatie • Het Document Object Model (DOM) voor dynamische interactie met de webpagina • XML voor opslag en transport van gegevens. Een alternatief is JSON (JavaScript Object Notation) • Het XmlHttpRequest-object voor asynchrone communicatie met de server • JavaScript om dit alles met elkaar te verbinden Toepassingen die gebruik maken van Ajax vereisen niet dat er extra plugins zijn ge¨ınstalleerd op de PC van de gebruiker. Het is wel noodzakelijk dat men beschikt over een browser die JavaScript ondersteunt. Ajax kan gebruikt worden om asynchroon data met de webserver uit te wisselen, zonder dat daarbij de pagina moet herladen worden. De webpagina, of een deel ervan, kan dan


16

ge¨ updatet worden eens de nieuwe data beschikbaar is. Het grote voordeel van deze manier van werken is dat de “statische” inhoud van de pagina (en dat is er doorgaans heel wat) niet steeds opnieuw moet worden verzonden. In dat opzicht verschilt het interactiemodel van Ajax met dat van een traditionele webtoepassing (Figuur 4.1). Het interactiemodel van een traditionele toepassing, bijvoorbeeld in ASP.NET, is gebaseerd op het request-response-model : een actie van de gebruiker zal ertoe leiden dat de browser een aanvraag (request) verstuurt naar een webserver. Die webserver zal een antwoord (response) terugsturen, en doorgaans zal dit een (volledige) webpagina zijn. Wanneer de browser het antwoord volledig heeft ontvangen, zal hij de huidige pagina volledig vervangen door de zopas ontvangen pagina. Dit heeft tot gevolg dat zelfs voor een kleine wijziging de hele pagina moet verstuurd en vervangen worden, wat meestal een niet zo vlotte indruk geeft. Ajax omzeilt deze manier van werken. Wanneer de gebruiker een actie uitvoert, wordt eerst een XmlHttpRequest-object aangemaakt. Als dat gebeurd is, wordt aangegeven op welke manier het resultaat van de aanvraag moet worden verwerkt, wanneer het resultaat bekend is.

Dit kan men doen door aan het onreadystatechange-attribuut van het

XmlHttpRequest-object de gepaste callback-functie toe te wijzen. Wanneer men dat gedaan heeft kan men de aanvraag verzenden naar de server. var xmlHttp = GetXmlHttpObject(); xmlHttp.onreadystatechange = function() { //do work to process received data; } xmlHttp.open("POST", url, true); xmlHttp.send(data); Het antwoord van de server zal niet noodzakelijk een volledige pagina zijn, het kan ook gaan om slechts een klein deel ervan, zoals bijvoorbeeld een hoeveelheid XML-geformatteerde data. Wanneer de Ajax-engine dit antwoord ontvangt, zal de callback-functie uitgevoerd worden, en kan men bijvoorbeeld de ontvangen data toevoegen op de correcte plaats in de huidige pagina. Dit wordt verwezenlijkt door de DOM-boom van de pagina aan te passen. De DOMboom van een webpagina stelt de structuur van die pagina op een platformonafhankelijke manier voor. De knopen in de boom komen overeen met de verschillende elementen op de pagina, zoals bijvoorbeeld afbeeldingen, paragrafen, invulvelden... Met behulp van JavaScript is het mogelijk om die DOM-boom dynamisch aan te passen: men kan nieuwe elementen toevoegen aan de boom, of bestaande elementen wijzigen of verwijderen. Wanneer men na een asynchrone aanvraag de pagina wil updaten, zal de callback-functie bijvoorbeeld zorgen dat er op de gepaste plaats een nieuwe knoop wordt toegevoegd aan de DOM-boom. Het resultaat


17

Figuur 4.1: Interactiemodel Ajax zal onmiddellijk zichtbaar zijn voor de gebruiker, zonder dat de volledige pagina daarvoor moet worden ververst. Een gevolg van deze aanpak is dat de browser er geen weet van heeft dat de pagina’s dynamisch zijn aangepast. Het gebruik van de vorige-knop zal dus niet noodzakelijk leiden tot de vorige toestand van de Ajax-pagina. Hierdoor is het ook niet mogelijk een bepaalde toestand van de pagina op te slaan, in bijvoorbeeld de favorieten, voor later hergebruik. Misschien wel het grootste nadeel van Ajax is dat er geen standaard achter schuilt, waardoor de manier van werken verschilt van browser tot browser. Het verkrijgen van een XmlHttpRequest-object, als het ware de motor binnen Ajax, gebeurt in Mozilla Firefox als volgt: var XmlHttp = new XmlHttpRequest(); terwijl het in Internet Explorer eerder op deze manier gebeurt: var XmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); De laatste manier zal trouwens niet werken voor alle versies van Internet Explorer. Dit alles maakt dat het ontwikkelen van Ajax-toepassingen zeker niet eenvoudig is, net omdat men dient rekening te houden met de vele verschillen tussen de browsers. Gelukkig bestaan er verschillende manieren om de ontwikkeling toch eenvoudiger te maken. Zo zijn er bijvoorbeeld talrijke JavaScript-frameworks voorhanden die abstractie


18

maken van de onderlinge verschillen tussen browsers, en die het dus toelaten om op uniforme wijze Ajax-toepassingen te schrijven. De frameworks zullen er dan voor zorgen dat de toepassingen correct zullen werken in verschillende browsers.

Google Web Toolkit Een voorbeeld van zo’n framework is de Google Web Toolkit (GWT) [11]. De GWT laat toe de applicaties te ontwikkelen in een Java-omgeving. Na het ontwikkelen zal de GWT de code dan compileren tot geoptimaliseerde JavaScript-code die wel zal werken in alle belangrijkste browsers. Door het werken in een Java-omgeving is het ook mogelijk de code op een verbeterde manier te debuggen. De GWT biedt een ruime bibliotheek aan van UI-componenten, widgets genaamd. Deze widgets variëren van eenvoudige HTML-primitieven (Checkbox, Button...) over containerelementen (verschillende soorten Panels) tot complexere componenten (RichTextArea, SuggestBox). De GWT is ook in staat om de browsergeschiedenis te beheren, zodat de vorige-, volgendeen vernieuwknoppen van de browser functioneren zoals gewenst is.

jQuery jQuery [12] is een JavaScript-bibliotheek die ontwikkeling van rijke internettoepassingen met behulp van HTML en JavaScript een stuk eenvoudiger maakt. Met jQuery is het erg eenvoudig om de DOM-structuur van een pagina te doorlopen, events af te handelen en zelfs een vorm van animaties toe te voegen aan een webpagina. Bovendien biedt jQuery ook een heel eenvoudige manier aan om Ajax-interactiviteit te voorzien, op een browseronafhankelijke wijze. Dezelfde functionaliteit als in het JavaScript-fragment hierboven kan met behulp van jQuery bekomen worden als volgt: $.post(url, data,function(xml) { //do work to process received data; }); jQuery maakt het mogelijk om op een erg compacte manier efficiënte code te schrijven, die toch overzichtelijk en intu¨ıtief blijft. De jQuery UI bibliotheek [13] is gebouwd bovenop de standaard jQuery bibliotheek en voorziet mogelijkheden om de webtoepassing rijker te maken. jQuery UI biedt daarvoor verchillende widgets (Accordion Panel, DatePicker, Progressbar...) aan maar ook verschillende grafische effecten (verschijnen, in- en uitfaden, oprollen...). Met JQuery UI is het ook mogelijk om meer geavanceerde interacties toe te voegen aan een webtoepassing. Zo is het bijvoorbeeld mogelijk om bepaalde delen van de pagina te verslepen of van grootte te veranderen.


19

Andere frameworks Er bestaan nog tal van andere frameworks die het werken met Ajax makkelijker maken. Een voorbeeld is het ASP.NET Ajax-framework (vroeger: Atlas) [14], dat kan gebruikt worden om op een eenvoudige en efficiënte manier Ajax-applicaties te bouwen, binnen de ontwikkelingsomgeving van Visual Studio. Andere frameworks zijn Mootools, Prototype, Yahoo! UI Library, Pyjamas... Een gemeenschappelijk voordeel van die frameworks is dat ze ook over bepaalde User Controls beschikken. Dit zijn voorgeprogrammeerde componenten (zoals bijvoorbeeld knoppen, checkboxes... maar ook meer geavanceerde zoals panels, datagrids, tekst editors...) die naar believen kunnen gebruikt worden in de eigen applicaties. Het voordeel hiervan is dat je heel wat tijd kan besparen bij het ontwikkelen van applicaties door het doordacht gebruik van dergelijke componenten, omdat een groot deel van de functionaliteit (layout, event-afhandeling...) al geprogrammeerd is. Het is meestal ook mogelijk om eigen componenten te bouwen (meestal op basis van reeds bestaande), die men dan later kan hergebruiken in andere applicaties.

4.2.2

Adobe Flex

Een andere veelgebruikte technologie voor de ontwikkeling van RIA’s is Adobe Flex [15]. Flex is een open source framework1 om RIA’s te onwikkelen die consistent kunnen gebruikt worden in de meest gebruikte browsers en besturingssystemen. Om gebruik te kunnen maken van een applicatie ontwikkeld met Flex is het noodzakelijk dat de Adobe Flash Player is ge¨ınstalleerd op de computer van de gebruiker, maar aangezien dit reeds het geval is op 97% van de huidige desktopcomputers [16], is dit niet echt een beperking. Flex maakt gebruikt van MXML, een XML-gebaseerde opmaaktaal, om grafische gebruikersinterfaces te bouwen. Interactiviteit in Flex-applicaties wordt bekomen door het gebruik van ActionScript, een scripting taal gebaseerd op ECMAScript. Voor de lay-out kan men gebruik maken van CSS (Cascading Style Sheets) om zo de opmaak van de inhoud te scheiden. Flex applicaties kunnen ontwikkeld worden binnen de Flex Builder-ontwikkelingsomgeving. In de Flex Builder kan men via de design-mode eenvoudig componenten toevoegen aan de gebruikersinterface door ze naar de juiste plaats te verslepen en hun eigenschappen naar believen aan te passen. In source-mode kan men zelf sleutelen aan de MXML-broncode om een grotere flexibiliteit te verkrijgen, of om bijvoorbeeld extra functionaliteit toe te voegen met behulp van ActionScript. Eens de applicatie ontwikkeld is, wordt die gecompileerd naar een 1

“Open source” is hier met een korreltje zout te nemen: de Flex SDK, die enkel een compiler en

de component-bibliotheek bevat, is weliswaar open source en dus gratis beschikbaar, maar wanneer men gebruik wenst te maken van de Flex Builder IDE, de uitgebreide ontwikkelingsomgeving voor Flex-toepassingen, moet men toch een betalende licentie aanschaffen.


20

SWF-bestand dat kan ingebed worden in een webpagina. Een nadeel hierbij is dat de inhoud van een SWF-bestand niet indexeerbaar is door zoekmachines, dus de tekstuele inhoud van de applicatie moet op een andere manier beschikbaar zijn indien men gevonden wil worden via zoekmachines. De Flex SDK biedt een erg ruime bibliotheek van herbruikbare componenten aan. Naast de eenvoudige zaken als tekstvelden of knoppen, zijn er ook verschillende geavanceerde componenten om data op een overzichtelijke manier weer te geven, zoals de DataGrid, AdvancedDataGrid, Tree... Daarnaast zijn er ook nog verscheidene container-componenten (Grid, Panel, VBox, HBox...) en navigator-componenten (Accordion, TabNavigator...) om overzichtelijke navigatie te voorzien in de applicatie. Flex biedt ook de mogelijkheid om op eenvoudige wijze grafieken weer te geven (BarChart, LineChart, PieChart...). Het is heel eenvoudig om in een Flex-applicatie beelden of geluid te integreren. Wanneer men ook video wil toevoegen is men echter beperkt tot het FLV-containerformaat (Flash Video). Tot voor kort hield dit in dat men voor de videobitstromen beperkt was tot een variant van H.263, namelijk de proprietaire Sorenson Spark codec [17, 18]. Sinds de recentere versies van de Flash Player (vanaf versie 9, update 3) kan men echter ook gebruik maken van de wijdverspreide H.264-videocodec [19]. Deze laatste levert een significant betere kwaliteit/bitrate verhouding. Het ook is mogelijk om videobestanden te streamen naar een Flex-applicatie. Hiervoor moet men aan de server-zijde wel beschikken over een Flash Media Server. De precisie waarmee men kan navigeren in een videobestand is afhankelijk van het keyframe-interval binnen de FLV-video die men gebruikt. Men kan tot op een duizendste van een seconde nauwkeurig een positie opgeven naar waar men wil springen, maar in de praktijk zal er gesprongen worden naar het keyframe dat het dichtst bij die positie ligt. Het interval van dergelijke keyframes in het FLV-bestand, en dus ook de precisie waarmee men kan navigeren, is dus afhankelijk van de manier waarop de FLV-video werd geëncodeerd. Dit alles maakt dat Flex geschikt is voor applicaties waar men gebruik wenst te maken van videofragmenten. Dit uit zich ook in het feit dat veel van de hedendaagse populaire videosites (YouTube, Yahoo! Video, metacafe...) gebruik maken van Flex/Flash om hun video’s weer te geven. De uitwisseling van data tussen een Flex-applicatie en de server kan gebeuren via XML, maar ook via AMF (Adobe Action Message Format). Dit laatste is een binair formaat voor data-overdracht, dat veel sneller en compacter is dan de equivalente XML-berichten. Men kan dan met de objecten op de server (bijvoorbeeld Java-objecten) werken alsof het lokale objecten zijn in de Flex applicatie. Dit kan dus een erg handige manier zijn om vlot data weer te geven en te versturen tussen client en server. Het is wel noodzakelijk dat men werkt met een AMF-compatibele server, zoals BlazeDS [20]. De Flex-technologie maakt het ook mogelijk om toepassingen te ontwikkelen die kunnen uitgevoerd worden buiten de browser, op een platformonafhankelijke manier. Hiervoor wordt


21

de Adobe Integrated Runtime (AIR) gebruikt [21]. AIR maakt het mogelijk om met behulp van bestaande webtechnologiën rijke internetapplicaties te ontwikkelen die draaien in een desktopomgeving, zonder beperking van het besturingssysteem. Men kan AIR-toepassingen ontwikkelen door bijvoorbeeld gebruik te maken van HTML, JavaScript, en dus ook van Flex.

4.2.3

Microsoft Silverlight

De laatste technologie die hier besproken wordt is Silverlight, Microsofts inbreng in de wereld van RIA-ontwikkeling [22]. Silverlight is een relatief nieuwe technologie: de eerste release vond pas plaats in april 2007. Silverlight-applicaties kunnen uitgevoerd worden via een browserplugin die het mogelijk maakt animaties, audio en video weer te geven in een webbrowser. De plugin is momenteel compatibel met de meeste browsers op Microsoft Windows en Mac OS X-besturingssystemen. Momenteel is er nog geen ondersteuning voor Linux, maar er is wel een open source third-party implementatie in ontwikkeling, onder de naam Moonlight [23]. Er wordt ook ondersteuning voorzien voor mobiele toestellen. Silverlight werd ontwikkeld onder de naam Windows Presentation Foundation/Everywhere (WPF/E) en bevat een deel van het .NET Framework [10]. De lay-out van de gebruikersinterface in Silverlight-applicaties wordt hoofdzakelijk beschreven aan de hand van XAML (Extensible Application Markup Language), een taal gebaseerd op XML. De XAML-bestanden worden niet gecompileerd, waardoor de tekstuele inhoud van de Silverlight-applicaties indexeerbaar is voor zoekmachines, wat een belangrijk voordeel is. Een andere mogelijkheid is dat de XAML-code dynamisch gegenereerd wordt door een server-applicatie, wat voor een hogere aanpasbaarheid zorgt. De implementatie van de programma-logica achter de XAML-lay-out kan gebeuren in elke .NET taal. Doordat Silverlight gebaseerd is op (een deel van) het .NET Framework, kan de ontwikkeling van applicaties gebeuren in Microsoft Visual Studio, de vertrouwde ontwikkelingsomgeving voor .NET applicaties. Het is wel nodig dat men daarvoor de Silverlight Tools for Visual Studio installeert. Men kan dan via de design- of code-view het XAML-bestand opbouwen. Voor meer geavanceerde applicaties kan men gebruik maken van Microsoft Expression Studio, de speciaal ontwikkelde ontwikkelingsomgeving voor Silverlight. Doorgaans wordt het design van een applicatie ontwikkeld in Expression Studio, waarna het ontworpen XAML-bestand dan in Visual Studio wordt ge¨ımporteerd. Daar kan er verder logica en functionaliteit aan de applicatie worden toegevoegd. Zo is het mogelijk dat designers en ontwikkelaars afzonderlijk van elkaar aan een applicatie kunnen werken. Ook Silverlight biedt een ruim assortiment aan UI-componenten aan, en men kan gebruik maken van templates om de lay-out ervan aan te passen. Zo is het mogelijk om snel en eenvoudig de lay-out van de volledige applicatie te veranderen. Deze manier van werken is te vergelijken met het gebruik van CSS-bestanden bij Flex-toepassingen.


22

Silverlight is uitermate geschikt voor het creëren van multimedia-applicaties. Het is wel zo dat het aantal ondersteunde bestandsformaten voor Silverlight versies 1 en 2 eerder beperkt is. Voor wat betreft audio worden enkel MP3 en WMA ondersteund, voor video is dit enkel WMV en VC-1. Microsoft biedt wel gratis de Media Encoder aan, die toelaat andere formaten te converteren naar de ondersteunde types. In de recentste versie van Silverlight, versie 3 (betaversie beschikbaar sinds 18 maart 2009), is er wel ondersteuning voor AAC-audio en H.264-video, wat een belangrijke verbetering is. De interactie met data in Silverlight kan op een eenvoudige manier gebeuren aan de hand van XML. Data geformatteerd volgens een XML-schema kan op eenvoudige wijze gebonden worden aan één van de datacontrole-elementen in Silverlight (DataGrid, ListBox...). Een andere manier om met externe data te communiceren is via webservices. Het gebruik van webservices binnen Silverlight is erg eenvoudig gemaakt. Voorwaarde is wel dat de webservice die men wenst te gebruiken een ASMX- (ASP.NET Web Service) of een WCF- (Windows Common Foundation) web service is. Het is bijvoorbeeld niet mogelijk om rechtstreeks met een WSDL-service te communiceren. Vanaf versie 3 worden ook zogeheten Out-of-Browser-experiences ondersteund. Silverlighttoepassingen kunnen met andere woorden op het systeem ge¨ınstalleerd worden voor offline gebruik, zolang de webtoepassing dit toelaat tenminste. Deze lokaal ge¨ınstalleerde toepassingen zullen echter nog steeds uitgevoerd worden in een sandbox omgeving.

4.2.4

Andere

Er zijn uiteraard nog tal van andere technologiën die gebruikt kunnen worden voor de ontwikkeling van RIA’s. De uitgebreide bespreking wordt beperkt tot de drie belangrijkste technologiën. Hieronder volgt een kort overzicht van enkele alternatieven [10]. Java Applet [24] Een Java Applet is een klein Java-programma dat kan draaien in een browser. Men kan hierin gebruik maken van onder andere de Java Swing-bibliotheek om een grafische gebruikersinterface te maken. Om Applets te kunnen bekijken moet de gebruiker de Java Runtime Environment (JRE) ge¨ınstalleerd hebben. JavaFX [25] JavaFX is een softwareplatform dat volledig ge¨ıntegreerd is in de JRE. JavaFXtoepassingen worden gemaakt met behulp van de declaratieve taal JavaFX Script. Men kan de JavaFX-code compileren tot een Java Applet, of tot een Java Web Starttoepassing (toepassing die gestart wordt via een URL in de browser). OpenLaszlo [26] Dit is een open source platform bestaande uit de LZX programmeertaal en de OpenLaszlo Server. De OpenLaszlo Server is een Java Servlet die de LZXcode compileert naar uitvoerbare bestanden die in de browser kunnen getoond worden (bijvoorbeeld een DHTML-pagina of een SWF-bestand).

4.3. BESLUIT

23

Curl [27] Curl is een objectgeoriënteerde programmeertaal voor de ontwikkeling van RIA’s. HTML wordt gecombineerd met scripting (bv JavaScript) en volwaardige programmeertalen (Java, C#, C++...) binnen één enkele framework.

4.3

Besluit

Het is duidelijk dat er tegenwoordig enorm veel mogelijkheden zijn om rijke internettoepassingen te ontwikkelen. In Tabel 4.1 wordt een overzicht gegeven van de 3 besproken technieken. Deze technieken worden op verschillende gebieden met elkaar vergeleken. Het blijkt dat er niet één grote winnaar uit de bus komt. De beslissing van welke techniek men gebruikt zal afhangen van de aard van de toepassing. Wanneer men nood heeft aan een eenvoudige manier om multimediale bestanden op te nemen in de applicatie, dan zal Ajax geen onmiddellijk bruikbare oplossing aanbieden en zal men eerder zijn toevlucht moeten nemen tot Flex of Silverlight. Voor eenvoudigere toepassingen waar men de gebruiker zo weinig mogelijk overlast wil bezorgen met het installeren van extra software kan men met Ajax al een heel eind ver geraken, zeker als men er in slaagt een geschikt framework te vinden waarvan de applicatie gebruik kan maken. In de praktijk zal men zich echter zelden beperken tot één enkele technologie, maar gebruik maken van een combinatie van meerdere technologieën. Sites die bijvoorbeeld gebruik maken van een Flex-videospeler zullen ook nog dikwijls gebruik maken van Ajax om de rest van de gebruikersinterface responsiever te maken. Dit zal ook de strategie zijn die wordt gebruikt in de gebruikersinterface die hier ontwikkeld wordt. Het grootste deel van de layout wordt gebouwd met behulp van het jQuery-framework, maar de lageresolutieversies worden afgespeeld door middel van een videospeler die ontwikkeld is in Flex. De Ajax-functionaliteit van jQuery wordt gebruikt om asynchroon data uit te wisselen met de server. Hoewel men in staat zou moeten zijn om met Silverlight dezelfde soort toepassingen te ontwikkelen als met Flex, kan men zich toch de vraag stellen of Silverlight eigenlijk wel een meerwaarde biedt. Op de meeste hedendaagse computers is de Flash Player reeds ge¨ınstalleerd, dus waarom zou een gebruiker de moeite nog willen doen om ook de Silverlight plugin te installeren? Iets gelijkaardigs kan gezegd worden over de webontwikkelaars die nu vlot overweg kunnen met Flex (en bij uitbereiding Flash): waarom zouden zij de moeite nemen om te leren werken met Silverlight? Daartegenover staat dan wel dat een groot aantal .NET ontwikkelaars zich nu ook kunnen storten op het domein van de rijke webapplicaties. Ook het feit dat de Flash Player wijdverspreid is, lijkt een argument te zijn dat vooral gebruikt wordt als excuus door mensen met een - niet objectieve - afkeer voor Microsoft producten: de Flash Player is immers ook ooit ge¨ınstalleerd geweest op het systeem, dus de installatie van de plugin zou eigenlijk geen beslissende factor mogen zijn. De Silverlight-plugin neemt

Tabel 4.1: Vergelijking RIA-technologiën

ok

Toegankelijkheid

voor zoekrobots

XML, JSON, tekst

ongecompileerd dus doorzoekbaar

.swf-file)

XAML-code

XML

.NET

XAML, JavaScript,

(gecompileerd tot

niet

XML, AMF

MXML, CSS

DOM, XHTML, CSS. . .

ActionScript,

Studio

omgeving

(functionaliteit)

(ontwerp) of Visual

Expression Studio

Vlotte ontwikkelings-

Flex Builder =

JavaScript, XML,

Data-uitwisseling

Technologiën

omgeving

Ontwikkelingsomgeving Geen specifieke

H.264 en AAC

In recente versies ook H.264 en AAC

Vanaf versie 3 ook

VP6.2), MP3.

codecs

WMA.

(Sorenson Spark,

aanwezige plugins,

WMV, VC-1, MP3,

(Linux: Moonlight)

op Mac en Windows.

Populairste browsers

Silverlight plugin

Zeer rijke ervaring

Microsoft Silverlight

Flash Video

Universeel

Adobe Flash Player

Zeer rijke ervaring

Adobe Flex

Afhankelijk van

Universeel

Platform

Mediaformaten

Enkel browser

met HTML

Goed in vergelijking

Installatievereisten

Gebruikerservaring

Ajax

4.3. BESLUIT 24

4.3. BESLUIT

25

wel iets meer plaats in dan de Flash Player. Het is dus nog onduidelijk of Silverlight ooit op gelijke hoogte van Flex/Flash zal komen. Microsoft blijft in ieder geval zijn best doen om Silverlight zo veel mogelijk te verspreiden bij de eindgebruikers, zo blijkt ook uit het feit dat men nu Silverlight probeert te promoten door het te gebruiken bij het online-archief van oude Playboy-nummers [28].

26

Hoofdstuk 5 Systeemarchitectuur In dit hoofdstuk wordt beschreven hoe het mediabeheersysteem precies is opgebouwd. Eerst wordt aan de hand van twee belangrijke use cases nagegaan waartoe het systeem in staat moet zijn. Uit deze use cases worden dan vervolgens de belangrijkste bouwblokken van het systeem afgeleid, en er wordt besproken welke functionaliteit deze voorzien. Tenslotte wordt aan de hand van enkele typische gebruikersscenario’s nagegaan hoe deze verschillende bouwblokken met elkaar interageren. In dit hoofdstuk wordt vooral een globaal overzicht van het systeem gegeven, in hoofdstukken 6 en 7 wordt dan meer gedetailleerd besproken hoe de twee use cases precies worden verwezenlijkt.

5.1 5.1.1

Use cases Ingest procedure

De eerste belangrijke use case, is die van de ingest-procedure (Figuur 5.1). Deze beschrijft de stappen die moeten worden ondernomen door een gebruiker om een nieuw media item toe te voegen aan het mediabeheersysteem. Hierbij moet de gebruiker een bestand kunnen uploaden. Voor ieder bestand dat wordt ge¨ upload moeten er onmiddellijk enkele keyframes en een lageresolutieversie gegenereerd worden. Uit deze use case kan afgeleid worden dat er zeker een component zal nodig zijn die instaat voor het beheer van de items. Er moeten ook voorzieningen zijn om bestanden te kunnen uploaden. Daarnaast moet het systeem ook in staat zijn om de mediabestanden te verwerken. Tenslotte zal er ook een component moeten voorzien worden die toelaat dat gebruikers zich kunnen aanmelden bij het systeem.

5.2. COMPONENTEN

27

Login

Upload File <>

<> Add new Item

Generate Keyframes <>

User

Generate Low Resolution version

Figuur 5.1: Use case: ingest procedure

5.1.2

Gebruik van metadata

In deze tweede use case (Figuur 5.2) staat de metadata centraal. Enerzijds moet het mogelijk zijn om items op te zoeken in het systeem, en metadata zal een belangrijke rol spelen om items te identificeren. Daarom is het ook wenselijk dat de gebruiker in staat is om via het systeem metadata informatie toe te voegen aan de items. Er zal dus zeker een component moeten voorzien zijn die instaat voor het beheer van deze metadata, evenals een systeem dat het mogelijk maakt het mediabeheersysteem te doorzoeken.

5.2

Componenten

Uit de vooraf besproken use cases worden de verschillende bouwblokken afgeleid die nodig zijn om de gewenste functionaliteit van het systeem te voorzien. Gerelateerde functionaliteiten worden samengebracht in een deelsysteem. Op die manier worden 6 grote deelsystemen bekomen. In Figuur 5.3 wordt getoond hoe deze met elkaar worden gecombineerd. De deelsystemen zullen uiteindelijk worden ge¨ımplementeerd als Java-packages. In sommige van die packages zijn één of meerdere Java Servlets aanwezig. Deze Servlets zorgen voor functionaliteit die rechtstreeks kan worden aangesproken door de gebruiker. In de praktijk zullen deze Servlets worden aangeroepen via Ajax om zo in de browser te worden weergegeven. In deze sectie worden de verschillende deelsystemen beschreven.

5.2. COMPONENTEN

28

Login

Search Item User

Edit Metadata

Update Item

<>

Figuur 5.2: Use case: gebruik van metadata

trigger media operations

uploadsystem

add item

mediamanagement

usermanagement

get file location

itemmanagement

describe item

metadatamanagement

get user information

Figuur 5.3: Architectuur van het mediabeheersysteem

tools

5.2. COMPONENTEN

5.2.1

29

Gebruikersbeheer

Het is de bedoeling dat heel wat verschillende gebruikers kunnen interageren met het systeem. Van al deze gebruikers moeten enkele belangrijke gegevens bijgehouden worden. Het deelsysteem dat instaat voor het bijhouden en bewerken van deze gegevens is het gebruikersbeheersysteem. In Figuur 5.4 is te zien hoe dit deelsysteem is opgebouwd.

User De centrale klasse binnen het gebruikersbeheer deelsysteem is de User klasse. De User klasse wordt gebruikt om informatie over de gebruikers van het systeem te beschrijven. Er wordt persoonlijke informatie bijgehouden (naam, (email-)adres, wachtwoord...) maar ook informatie over de organisatie waartoe de gebruiker behoort, en de rol die de gebruiker speelt binnen deze organisatie. De informatie die bijgehouden wordt is dezelfde die noodzakelijk is voor registratie bij EBU Technical, de technische arm van de European Broadcasting Union. De User objecten worden gelinkt aan een tabel in de databank, zodat de gebruikersgegevens bewaard kunnen worden.

ResetPassword Binnen het gebruikersbeheersysteem is ook één servlet aanwezig, namelijk ResetPassword. Deze servlet verwerkt aanvragen om een nieuw wachtwoord in te stellen voor een gebruiker. Dit kan gebeuren wanneer een gebruiker er zelf voor kiest zijn wachtwoord te wijzigen, maar ook wanneer een gebruiker zijn huidig wachtwoord vergeten is. In het laatste geval wordt er een nieuw wachtwoord gegenereerd en doorgemaild naar die gebruiker.

usermanagement HttpServlet

User

ResetPassword

Figuur 5.4: Deelsysteem gebruikersbeheer

5.2. COMPONENTEN

5.2.2

30

Itembeheer

Het itembeheersysteem (Figuur 5.5) staat in voor het toevoegen van nieuwe media items aan het systeem, en het weergeven van informatie over deze items aan de gebruiker. Ook wanneer er aan een item wijzigingen moeten worden aangebracht, zorgt het itembeheersysteem ervoor dat dit correct gebeurt.

Item De Item klasse is zonder twijfel de belangrijkste van het hele systeem. Deze klasse wordt gebruikt om een media-item te beschrijven dat wordt beheerd door het systeem. Alle Itemobjecten worden persistent gehouden door ze op te slaan in de databank. Wanneer een nieuw-media item wordt toegevoegd, wordt er een itemID aan toegekend. Dit itemID is uniek, waardoor het item nu ondubbelzinnig identificeerbaar is binnen het systeem. Er wordt ook bijgehouden wie het item heeft toegevoegd, en wanneer dit is gebeurd. Initieel voegt men ook al een beperkte hoeveelheid metadata toe, namelijk een titel en een optionele - korte beschrijving. Voor de meeste items zal dit niet voldoende zijn, en daarom kan men later nog extra metadata toevoegen. Hoe dit precies gebeurt wordt besproken in hoofdstuk 7. Wanneer een bestand wordt ge¨ upload dat bij het item hoort, wordt dit ook aangeduid in de databank. Om dit bestand te kunnen linken aan het item bewaart men de naam ervan, net zoals de locatie op de harde schijf waar het bestand is opgeslagen.

Search Een mediabeheersysteem dat een grote hoeveelheid items bevat, is volledig nutteloos als die items niet op een efficiënte en eenvoudige manier kunnen worden teruggevonden. Daarom werd er ook een zoekfunctie toegevoegd aan ons systeem. De Search-Servlet verwacht als parameter bij elke aanvraag een zoekterm, en zal dan deze aanvraag beantwoorden met een XML-geformatteerde lijst van items die aan die zoekterm voldoen. In hoofdstuk 7 wordt besproken hoe metadata wordt gebruikt om items terug te vinden.

ItemInformation Wanneer men een item in het systeem heeft teruggevonden, wenst men een gedetailleerd overzicht te krijgen van het item en de informatie die ermee gerelateerd is. De ItemInformation-Servlet staat hiervoor in. Op basis van het itemID wordt alle info over het item opgehaald en op een overzichtelijke manier geformatteerd om weer te geven binnen de webpagina.

5.2. COMPONENTEN

31

itemmanagement HttpServlet

ItemInformation

describres

Item

searches

Search

Figuur 5.5: Deelsysteem itembeheer

5.2.3

Uploadsysteem

Bij het toevoegen van nieuwe items aan ons mediabeheersysteem, speelt het uploadsysteem een cruciale rol. Via het uploadsysteem geeft de gebruiker een titel op voor het toe te voegen item, eventueel aangevuld met een korte tekstuele beschrijving ervan. Hierna kan de gebruiker het eigenlijke mediabestand selecteren om te uploaden naar het systeem. Het uploadsysteem zorgt ervoor dat deze upload correct afgehandeld wordt en dat het item effectief wordt toegevoegd aan ons mediabeheersysteem. De precieze werking van het ge¨ımplementeerde uploadsysteem wordt besproken in sectie 6.1.

5.2.4

Mediabeheer

Aangezien de bedoeling van het systeem is om mediabestanden te beheren, is het noodzakelijk dat het in staat is om enkele typische mediaoperaties uit te voeren op mediabestanden. Het mediabeheerdeelsysteem (Figuur 5.6) staat in voor alle functies die met dergelijke mediaoperaties te maken hebben.

KeyFrameGenerator Het is erg handig dat men voor ieder videofragement beschikt over enkele zogeheten keyframes. Dit zijn stilstaande beelden (afbeeldingen) die op bepaalde tijdstippen uit een videoframent worden gehaald. Aan de hand van dergelijke keyframes kan men zich snel een beeld vormen van de visuele inhoud van het videofragment. KeyFrameGenerator is een interface die functies aanbiedt voor het genereren van dergelijke keyframes. Ik heb ervoor gekozen om de keyframes te genereren met behulp van FFmpeg [29] en dus een klasse FFMPEGKeyFrameGenerator aangemaakt die KeyFrameGenerator implementeert. Wanneer men later echter de keyframes op een andere manier zou willen genereren, volstaat het om een nieuwe implementatie van KeyFrameGenerator te voorzien. De rest van de code kan dan nagenoeg ongewijzigd blijven.

5.2. COMPONENTEN

32

De methode createKeyFrame verwacht als parameters een itemId, een tijdscode (positie in het videofragment) en een afmeting. Er zal eerst in de databank worden gekeken of er reeds een keyframe gegenereerd werd voor dit item, met die tijdscode en afmeting. Wanneer dit het geval is wordt onmiddellijk de locatie op de schijf van dit keyframe teruggegeven. Wanneer nog geen dergelijk keyframe beschikbaar is, wordt een FFmpeg proces gestart dat het gewenste keyframe genereert. Als dit proces dit keyframe succesvol genereert, wordt de locatie ervan opgeslagen in de databank en daarna teruggegeven als resultaat van de methode. Op deze manier hoeft er enkel een FFmpeg proces gestart te worden wanneer het gewenste keyframe nog niet eerder werd gegenereerd, wat de uitvoeringstijd ten goede komt. De KeyFrames-Servlet zorgt ervoor dat de keyframes beschikbaar zijn via een URL van de vorm: http://[server]/KeyFrames?itemID=&timecode=&size=<WxH>

LowResGenerator Binnen een mediabeheersysteem kan het ook nuttig zijn om over één of meerdere lageresolutie versies van een videofragment te beschikken. Op die manier is het niet nodig dat een gebruiker het originele (grote) videobestand moet downloaden om het te kunnen bekijken. Die lageresolutieversies kan men dan afspelen in de browser aan de hand van een eenvoudige videospeler. FFMPEGLowResGenerator, een implementatie van de LowResGenerator interface, zorgt voor de generatie van dergelijke lageresolutieversies. De werking ervan is gelijkaardig aan die van de KeyFrameGenerator. De lageresolutieversies worden gegenereerd op basis van de gewenste afmeting en framerate. De LowResolution-Servlet maakt deze lageresolutieversies beschikbaar via een URL.

VideoInfoProvider De VideoInfoProvider wordt gebruikt om informatie te krijgen over een videobestand. Deze informatie bevat onder andere de afmeting en de duur van het fragment, evenals de gebruikte codec. Deze informatie wordt bekomen door een FFmpeg proces op te starten met als inputbestand de beschouwde video, maar zonder outputbestand. Dit proces zal geen bewerkingen uitvoeren op de de video, maar uit de output ervan kan de gewenste informatie worden afgeleid. Deze informatie wordt opgeslagen in de databank.

ProcessOutputHandler De ProcessOutputHandler is een hulpklasse die nodig is om toegang te hebben tot de output die gegenereerd wordt door de verschillende FFmpeg processen die worden opgestart door KeyFrameGenerator, LowResGenerator en VideoInfoProvider.

5.2. COMPONENTEN

33

Download Aan de hand van de Download -Servlet is het mogelijk om de originele videobestanden te downloaden. Wanneer de Download-Servlet een aanvraag binnenkrijgt voor een bestand, zal die eerst controleren of de gebruiker wel de toestemming heeft om het bestand te downloaden. Wanneer dit het geval is, zal dit gelogd worden in de databank en wordt het gewenste bestand gekopieerd naar de outputstream van de Servlet.

5.2.5

Metadatabeheer

Een item is meer dan enkel een mediabestand. Wil men in staat zijn op een efficiënte manier items terug te vinden in het systeem, dan is het noodzakelijk dat men zoveel mogelijk beschrijvende informatie toevoegt aan de items. Deze informatie noemen we de metadata. Het metadatabeheer systeem staat in voor alle functies die te maken hebben met het beheren van deze metadata. Deze functies omvatten het toevoegen van nieuwe metadata, het bewerken en verwijderen van bestaande metadata, maar ook het genereren van de noodzakelijke invulformulieren die de gebruiker te zien krijgt om voorgaande acties uit te voeren. In hoofdstuk 7 wordt er dieper ingegaan op de details van het metadatabeheer deelsysteem.

5.2.6

Tools

Dit deelsysteem bevat enkele algemene functies die door nagenoeg alle andere deelsystemen gebruikt worden en die dus niet kunnen worden ondergebracht in een ander deelsysteem. Een belangrijke functie van dit deelsysteem is het bijhouden van log-informatie over de acties die gebruikers ondernemen. In Figuur 5.7 is te zien uit welke klassen dit deelsysteem is opgebouwd.

MAMLogging De MAMLogging-klasse staat in het voor het loggen van gebruikersacties. Voorbeelden van dergelijke acties zijn het toevoegen van een item, het uploaden of downloaden van een mediabestand, het bewerken van de metadata horende bij een item, het al dan niet succesvol aanmelden van een gebruiker... Telkens wanneer een dergelijke actie uitgevoerd wordt zal de MAMLogger aangesproken worden om volgende gegevens bij te houden: • Het tijdstip waarop de actie wordt uitgevoerd. • Het userId van de gebruiker die de actie uitvoert. Indien geen userId beschikbaar is (bijvoorbeeld bij een onsuccesvolle inlog poging), wordt 0 gebruikt, aangezien er geen enkele gebruiker is met een dergelijke userId. • Het IP-adres van waarop de actie wordt uitgevoerd.

5.2. COMPONENTEN

34

mediamanagement KeyFrameGenerator

LowResGenerator

ProcessOutputHandler

FFMPEGKeyFrameGenerator

VideoInfoProvider

FFMPEGLowResGenerator

uses KeyFrames

uses Download

LowResolution

HttpServlet

Figuur 5.6: Package mediamanagement

5.3. INTERACTIE VAN DE COMPONENTEN

35

• Welke actie precies wordt uitgevoerd. Optioneel kan een korte beschrijving gegeven worden die wat meer info verschaft over deze actie. Al deze gegevens worden bijgehouden in een tabel in de databank. De MAMLogger werd echter zodanig ge¨ımplementeerd dat men de manier van opslaan zeer eenvoudig kan aanpassen. Op die manier zou men bijvoorbeeld de log-informatie kunnen bijhouden in een XML-bestand wanneer men daar behoefte aan heeft.

HelperTool De HelperTool -klasse is in staat enkele functies uit te voeren die vaak worden gebruikt. Deze functies hebben dikwijls te maken met het formatteren van een object (datum, afmeting...) op een bepaalde manier. Deze functies werden opgenomen in de HelperTool klassen, zodat de code niet overal moet gekopieerd worden op de vele plaatsen waar ze gebruikt worden.

5.3

Interactie van de componenten

Nu duidelijk is uit welke bouwblokken het systeem is opgebouwd, kan gekeken worden op welke manier deze bouwblokken met elkaar interageren. Dit wordt gedaan aan de hand van enkele veelvoorkomende gebruikersscenario’s.

5.3.1

Scenario: gebruikersbeheer

Het sequentiediagram van Figuur 5.8 beschrijft hoe een gebruiker zich registreert bij het systeem om zich later te kunnen aanmelden. Hij doet dit door via een webformulier de gevraagde persoonlijke informatie in te vullen en dit formulier te verzenden naar de server (1). Bij de verwerking van dit formulier zal er een nieuw User-object worden aangemaakt (2) waaraan dan de persoonlijke informatie wordt toegevoegd (3). Dit User-object wordt opgeslagen in de databank, zodanig dat de gebruiker in de toekomst in staat is zich aan te melden bij het systeem (6). Wanneer hij dat probeert, wordt gecontroleerd of de logingegevens

tools MAMLogger

HelperTool uses

Figuur 5.7: Deelsyteem tools


36

correct zijn (7) en indien dit het geval is, worden deze gegevens bijgehouden in een sessieobject (8), zodanig dat de gebruikergegevens beschikbaar zijn gedurende de sessie.

5.3.2

Scenario: doorzoeken van het systeem

In het sequentiediagram van Figuur 5.9 is te zien wat er gebeurt wanneer een gebruiker het systeem wenst te doorzoeken. De gebruiker verzendt een zoekterm naar de server (1). Het itembeheersysteem zal aan de hand van deze zoekterm de databank bevragen (2) en de gevonden resultaten formatteren in een XML-document (3) alvorens ze terug te zenden naar de gebruiker (4).

5.3.3

Scenario: aanpassen van metadata

Wanneer een gebruiker de metadata van een item wil aanpassen zal dat gebeuren zoals beschreven in het sequentiediagram in Figuur 5.10. Eerst zal de gebruiker de bestaande gegevens bekijken (1). Deze gegevens worden gelezen uit de databank (2) en vervolgens op een overzichtelijke manier opgemaakt (3) en naar de gebruiker teruggezonden (4). Wanneer de gebruiker vervolgens de metadata wil bewerken zal hij daarvoor een verzoek sturen naar het metadatabeheersysteem (5). Het metadatabeheersysteem zal daarop de gepaste invulformulieren genereren (6) en terugzenden naar de gebruiker (7). Deze gebruiker vult vervolgens dit formulier in (8) en verzendt het naar de server (9). Deze gegevens uit het formulier worden verwerkt door het metadatabeheersysteem (10) en het beschouwde item wordt ge¨ update (11). Deze update wordt ook doorgevoerd naar de databank, zodanig dat de nieuwe metadata voorgoed beschikbaar blijft. De details over onder andere de generatie van de invulformulieren worden besproken in hoofdstuk 7.


37

usermanagement User 1: send registration form 2: new User 3: addUserInformation 4: persistUser 5: registration succes

6: login 7: checkIfRegistered 8: createSession 9: login success

Figuur 5.8: Scenario: gebruikersbeheer

itemmanagement User 1: search term 2: query DB

4: search results

3: format results

Figuur 5.9: Scenario: doorzoeken van het systeem


itemmanagement User

38

metadatamanagement

1: view item details 2: read from DB 3: format details

4: item details 5: edit metadata

6: generate input form

7: input form 8: fill in form

9: submit form 11: update item 12: update DB 13: return 14: update succes

Figuur 5.10: Scenario: metadata aanpassen

10: process form

39

Hoofdstuk 6 Ingest workflow In dit hoofdstuk wordt dieper ingegaan op de stappen die worden ondernomen bij het toevoegen van nieuwe items aan het systeem, de zogeheten ingest-procedure. Vooreerst moet het bestand ge¨ upload worden naar de server, alvorens er verdere acties ondernomen kunnen worden. Na het uploaden zullen dan onmiddellijk enkele keyframes worden gegenereerd, en ook een lageresolutieversie die bekeken kan worden in de browser.

6.1

Upload

Een eerste stap bij het toevoegen van een item in het systeem, is het transfereren van het mediabestand naar de server. De bestanden die zullen worden ge¨ upload zijn doorgaans ruwe, ongecomprimeerde videobestanden, die erg groot kunnen zijn. De bestandsgroottes kunnen oplopen tot meer dan 50 gigabyte. Het uploadsysteem moet dus in staat zijn om met dergelijke grote bestanden overweg te kunnen, wat geen triviale vereiste is. Hieronder worden de verschillende pogingen beschreven die ondernomen zijn om dit te verwezenlijken.

6.1.1

Versie 1: HTTP Upload

In de oorspronkelijke versie van het uploadsysteem worden de bestanden via een standaard HTML-formulier over HTTP verzonden naar de server. Op de server staat een Servlet in voor de correcte afhandeling van deze upload. Hiertoe wordt in de webpagina een form-element opgenomen op dat in staat was om bestanden te verzenden:

6.1. UPLOAD

40

Wanneer de gebruiker op de submit knop drukt, wordt het bestand door de browser verzonden naar de server via een HTTP POST-request. De UploadServlet zorgt dan voor de verwerking van de ontvangen POST-data. De standaard Servlet API biedt geen methode aan om bestanden die via een HTTP POST ge¨ upload zijn te verwerken, maar er zijn wel enkele Java-bibliotheken beschikbaar die deze functionaliteit voorzien. Ik heb gekozen voor de FileUpload -bibliotheek [30] die een onderdeel is van het Apache Commons project [31]. Apache Commons is een open source project dat als doel heeft herbruikbare Java-componenten te ontwikkelen en te onderhouden. De FileUpload-component voorziet mogelijkheden om bestanden te uploaden binnen Java-webapplicaties. Er werd gekozen voor FileUpload, omdat dat een veelgebruikte, open source component is, waar veel documentatie over beschikbaar is. Bovendien is de component in ruime mate configureerbaar, wat bij de alternatieven niet altijd het geval was. Zo is het mogelijk om in te stellen wat de maximum toegestane grootte is van het ge¨ uploade bestand, maar belangrijker is dat men ook kan kiezen om net geen maximale grootte in te stellen. Dit is erg belangrijk in deze situatie, waar een bovenlimiet voor de bestandsgrootte niet gewenst is. De Streaming API van FileUpload maakt het bovendien mogelijk om de ontvangen bytes van het ge¨ uploade bestand rechtstreeks te streamen naar het uiteindelijk bestand op de server. Op die manier is het niet nodig om het gedeelte van het bestand dat reeds is ge¨ upload in het geheugen te bewaren, of weg te schrijven naar tijdelijke bestanden, alvorens het naar de correcte locatie op de harde schijf te kopiëren. Zo blijft het geheugengebruik tijdens de upload beperkt tot het minimum, wat de prestatie van het upload systeem optimaal maakt. Doordat de bestanden die ge¨ upload worden doorgaans erg groot zijn, zal het doorgaans een hele tijd duren alvorens het volledige bestand is ge¨ upload. Het is dus belangrijk om de gebruiker tijdens de upload feedback te geven over de huidige vooruitgang ervan. Het is immers niet wenselijk dat een gebruiker vruchteloos blijft wachten omdat er tijdens de upload iets is misgelopen, of een gebruiker er verkeerdelijk vanuit gaat dat er een fout is opgetreden en de upload opnieuw start. Daarom wordt er tijdens de upload een voortgangsbalk getoond die aanduidt hoever de huidige upload gevorderd is.

Overzicht van het uploadsysteem In Figuur 6.1 wordt schematisch weergegeven hoe de eerste versie van het uploadsysteem eruit ziet. Aan de client-zijde is er enkel de browser die instaat voor het verzenden van het formulier met het bijhorende mediabestand, en het opvragen van de statusinformatie van de huidige upload (via JavaScript). Aan de server zijde is er de UploadServlet die de aanvragen van de client verwerkt. Om het ge¨ uploade bestand te verwerken, gebruikt de UploadServlet een ServletFileUpload -object, een component uit de FileUpload-bibliotheek. Het is mogelijk om aan dit object een ProgressListener toe te wijzen, die informatie bijhoudt over de huidige upload. Het ServletFileUpload-object zal dan op regelmatige tijdstippen de update-methode

6.1. UPLOAD

41

Server

HttpServlet

Client Browser

POST file

UploadServlet

<> ProgressListener

read

FileUploadListener

GET status update

ServletFileUpload

Figuur 6.1: Architectuur uploadsysteem (versie 1) van die ProgressListener aanroepen en daarbij informatie doorgeven over de totale grootte van het bestand en de reeds getransfereerde bytes. Ik maakte een eigen implementatie van de ProgressListener-interface - de FileUploadListener klasse - die onder andere ook nog de bestandsnaam bijhoudt. Wanneer de browser dan vraagt naar de status van de upload, zal de UploadServlet de gevraagde informatie kunnen halen uit het FileUploadListener-object, dat gedurende de upload bijgehouden wordt als een sessie-object.

Interactie In Figuur 6.2 is te zien hoe de interactie tussen de componenten van het eerste uploadsysteem verloopt. • Op het moment dat de gebruiker op de submit knop drukt, wordt het formulier verzonden via een HTTP POST (1). • Wanneer de UploadServlet een dergelijke POST-aanvraag ontvangt, wordt eerst een nieuwe instantie van de ServletFileUpload-klasse aangemaakt (2). Deze klasse wordt later gebruikt om de aanvraag te parsen en het bestand te scheiden van de rest van de formulierinformatie. Er wordt ook een nieuwe FileUploadListener aangemaakt (3) en die wordt toegevoegd aan het sessie-object. • Deze FileUploadLisener wordt dan geregistreerd bij het ServletFileUpload-object, zodat die updates over de uploadstatus kan doorgeven (4).

6.1. UPLOAD

42

• Vervolgens wordt de POST-aanvraag effectief geparsed (5). Hierbij worden de tekstuele formuliervelden (titel en beschrijving van het item) samen met wat contextuele informatie (tijdstip van toevoegen, identificatie van de uploader...) toegevoegd aan de databank, terwijl het mediabestand wordt gekopieerd naar de correcte locatie op de harde schijf. Deze locatie is afhankelijk van de datum en van de organisatie van de uploader. • Op regelmatige tijdstippen (de frequentie is afhankelijk van de gebruikte servlet engine) zal het ServletFileUpload-object de update-methode van zijn geregistreerde FileUploadListener aanroepen en op die manier aanduiden hoeveel bytes er reeds ge¨ upload zijn (6). • Gelijktijdig hiermee loopt in de browser een JavaScript-script dat periodisch een asynchrone aanvraag stuurt naar de UploadServlet in verband met de status van de huidige upload (7). Het tijdsinterval tussen twee dergelijke aanvragen wordt dynamisch aangepast, op basis van de ogenblikkelijke snelheid van de upload. Op die manier zal er pas een aanvraag verstuurd worden als er een reële kans is dat de status van de upload susbstantieel gewijzigd is, waardoor de overhead ten gevolge van de status updates beperkt blijft. • Wanneer de UploadServlet een aanvraag voor een status update binnenkrijgt, zal deze de benodigde informatie opvragen aan het FileUploadListener-object, dat beschikbaar is via het sessie-object (8). • Vervolgens zal de UploadServlet een XML-geformatteerd antwoord terug sturen naar de browser dat informatie bevat over de totale lengte van het bestand en het aantal bytes dat reeds is verzonden (10). Deze informatie wordt door het script in de browser gebruikt om de voortgangsbalk aan te passen en de ogenblikkelijke uploadsnelheid te berekenen (Figuur 6.3).

Probleem Dit uploadsysteem werd uitvoerig getest en werkte probleemloos voor bestanden groter dan één gigabyte. Wanneer het systeem echter getest werd met realistische videobestanden met groottes van ongeveer 20 gigabyte bleek er echter een probleem te zijn: de upload werd nooit gestart, er werd zelfs geen data over het netwerk verstuurd. Na enkele testen bleek dat de limiet van de bestandsgrootte lag op iets minder dan 2 gigabyte, namelijk als de totale grote van de HTTP-request (headers inbegrepen) gelijk was aan 2 gigabyte. Aangezien 231 −1 in veel programmeertalen de maximum waarde is van een signed integer (door de woordbreedte van 32-bit-systemen), rees algauw het vermoeden dat een overflow aan

6.1. UPLOAD

43

: Browser

: UploadServlet

1: POST file 2: new

: ServletFileUpload

3: new

: FileUploadListener

4: setProgressListener 5: parseRequest

par

loop 6: update

loop

7: GET status 8: readStatus 9: status 10: status

Figuur 6.2: Sequentiediagram uploadsysteem (versie 1)

Figuur 6.3: Vooruitgang van de upload

6.1. UPLOAD

44

de basis kon liggen van dit probleem. De ontwikkelde code werd hierop grondig gecontroleerd, alsook de broncode van de FileUpload-bibliotheek, evenwel zonder resultaat. Alle relevante variabelen waren gedefinieerd als long integers en konden dus een waarde tot 263 −1 bevatten. De oorzaak moest dus elders gezocht worden. Na wat opzoekingswerk bleek het probleem in een onverwachte hoek te liggen. Het blijkt dat de hedendaagse browsers niet overweg kunnen met HTTP-requests die groter zijn dan 2 gigabyte [32]. Het zou dus op geen enkele manier mogelijk zijn om van binnenin een browser bestanden te uploaden van groter dan 2 gigabyte met een gewone HTTP-request. Het uploadsysteem werd later ook getest vanop een 64-bit-machine en daar was het wel mogelijk bestanden groter dan 2 gigabyte te uploaden. Dit is echter geen voldoende oplossing voor het probleem, aangezien 64-bit-systemen slechts door een minderheid gebruikt worden. Een andere manier om de mediabestanden te transfereren naar het mediabeheersysteem drong zich dus op.

6.1.2

Alternatieven voor HTTP upload

In dit onderdeel wordt overlopen welke alternatieven er zijn om de upload van grote mediabestanden te realiseren en welke oplossing het meest geschikt is voor deze toepassing. Onafhankelijk van de gebruikte technologie zijn er in grote lijnen twee mogelijke principes die gehanteerd kunnen worden. Enerzijds kan men opteren om de grote bestanden op te splitsen in kleinere delen, die men dan elk afzonderlijk kan uploaden, al dan niet via HTTP. De afzonderlijke delen moeten dan op de server opnieuw gecombineerd worden tot het originele bestand. Anderzijds kan men ook een andere protocol dan HTTP gebruiken voor het uploaden van de bestanden. FTP zou hier dan de logische keuze zijn. Geen van deze twee principes kan uitgevoerd worden door enkel gebruik te maken standaardtechnieken voor de ontwikkeling van webpagina’s, zoals HTML en JavaScript. Via geen van deze technieken kan men immers toegang krijgen tot lokale bestanden.

Externe toepassing Een eerste mogelijkheid om het probleem van de browserlimiet te omzeilen zou zijn om de gebruiker eerst een actie te laten uitvoeren buiten de browser, alvorens het item toe te voegen aan ons systeem. Deze actie zou erin kunnen bestaan om het bestand te splitsen in verschillende kleinere delen met behulp van een reeds bestaande toepassing (bijvoorbeeld (Win)RAR, of het split-commando in Linux). Via de webinterface zou de gebruiker dan al deze bestanden afzonderlijk kunnen uploaden met het reeds ge¨ımplementeerde uploadsysteem. Deze manier van werken is vrij omslachtig. De gebruiker moet een externe applicatie gebruiken, terwijl het doel was om één ge¨ıntegreerde oplossing te ontwikkelen waar alle acties kunnen uitgevoerd worden binnen de browser. Bovendien kan het bij grote bestanden tijdrovend zijn om

6.1. UPLOAD

45

alle delen van het bestand afzonderlijk te selecteren voor upload, wat vereist is door het beveilingsbeleid van de browsers. Een andere mogelijkheid zou zijn om de gebruiker te vragen om eerst het gewenste bestand te uploaden naar een FTP-server met behulp van een FTP-toepassing naar keuze. Wanneer de gebruiker dan het item zou toevoegen aan het mediabeheersysteem, zou hij het bijhorende bestand kunnen selecteren uit een lijst die alle ge¨ uploade bestanden bevat. Dit is ook de manier waarop bestanden worden ge¨ upload naar het huidige Ardome-systeem. Dit op zich is al veel minder omslachtig dan verschillende delen van een bestand afzonderlijk te moeten selecteren, maar op deze manier kan nog steeds niet voldaan worden aan de vereiste om alles binnen de browser zelf te kunnen afhandelen.

Flex applicatie binnen de webpagina Binnen een Flex applicatie is het mogelijk om gebruik te maken van een FileReference klasse voor interactie met lokale bestanden. Bij oudere versies van de Flash Player (tot en met versie 9) kon men die klasse enkel gebruiken om bestanden te downloaden van een server, of te uploaden vanaf de harde schijf en dus niet om toegang te krijgen tot de bestanden zelf. Om veiligheidsreden is de server waarnaar of waarvan men uploadt respectievelijk downloadt beperkt tot dezelfde server waarvan de Flex applicatie gedownload werd. De maximale grootte van bestanden die men kan uploaden met de Flash Player is officieel 100 megabyte, maar dit lijkt geen harde limiet te zijn. Ook bestanden groter dan 100 megabyte kunnen worden ge¨ upload, maar ook hier geldt dezelfde beperking als bij de browsers: bestanden groter dan 2 gigabyte kan men niet uploaden. Dit komt doordat de upload -methode van de FileReferenceklasse vertaald wordt naar een gewone HTTP POST via de browser. De standaard uploadmethode levert dus geen bruikbare oplossing. Sinds Flash Player 10 is het echter wel mogelijk om toegang te krijgen tot de lokale bestanden. Men kan een bestand selecteren en dan via de load -functie de volledige inhoud ervan lezen als een byte-array. Omgekeerd kan men ook een byte-array wegschrijven naar een bestand op de lokale harde schijf. In theorie zou het dus mogelijk zijn een groot bestand in te lezen en de verkregen byte array op te splitsen in delen die kleiner zijn dan 2 gigabyte. Die kleinere delen zou men dan afzonderlijk kunnen opslaan en de aldus verkregen bestanden zou men één voor één kunnen uploaden, zonder dat men hinder ondervindt van de limiet van 2 gigabye. In de praktijk is deze oplossing echter niet haalbaar. Vooraleer men bewerkingen kan doen op de originele byte-array, moet deze eerst volledig in het werkgeheugen geladen worden. Wanneer men dus met realistische mediabestanden werkt zal het onmogelijk zijn om die volledig in te lezen en zal het splitsen ervan dus ook niet mogelijk zijn. Een ideale situatie zou zijn wanneer men de bestanden zou kunnen lezen en schrijven als een stream. Men zou dan de bytes kunnen kopiëren naar een nieuw (kleiner) bestand en dan dit bestand uploaden zodra de grootte ervan 2 gigabyte bereikt. Dit is echter nog niet mogelijk in de huidige versies

6.1. UPLOAD

46

van de Flash Player, maar werd wel reeds voorgesteld voor de komende versies. Binnen Flex is het ook mogelijk om te werken met sockets, op voorwaarde dat men de socketverbindingen authoriseert door middel van een socketbeleidsbestand. Men zou dus in principe een verbinding kunnen openen met een FTP-server om het bestand op die manier te uploaden. Maar ook hier zal dit in de praktijk niet mogelijk zijn aangezien de lokale bestanden enkel toegankelijk zijn via een byte-array die volledig in het geheugen moet worden gelezen. Binnen het AIR-framework, de desktop variant van de Flash Player, is het reeds mogelijk om toegang te krijgen tot een bestand via een stream, dus het is realistisch om te verwachten dat dit ook mogelijk zal zijn in één van de komende versies van de Flash Player. Zolang dit nog niet het geval is, moet er nog gezocht worden naar een andere oplossing.

Silverlight toepassing In een Silverlight-toepassing is het mogelijk om bestanden in te lezen vanaf de harde schijf van de gebruiker. De enige voorwaarde hiervoor is dat de gebruiker zelf dat bestand selecteert via een dialoogvenster. Op die manier wordt voorkomen dat de ontwikkelaar van de Silverlight-toepassing zelf gaat beslissen welke lokale bestanden er gebruikt worden. Wanneer de gebruiker een bestand selecteert, is het mogelijk om via een stream toegang te krijgen tot dat bestand. Het bestand moet dus niet eerst volledig in het geheugen worden gelezen. Dankzij het concept van Isolated Storage is het mogelijk om vanuit de Silverlight-applicatie tijdelijk bestanden op te slaan op de harde schijf van de gebruiker. Het is dus mogelijk om het originele bestand op te splitsen in kleiner bestanden en die bestanden dan via een gewone HTTP-upload te verzenden naar de server. Aangezien het lokale bestand echter toegankelijk is via een stream, is het veel efficiënter om die stream rechtsreeks te uploaden naar de server, zonder een omweg via tijdelijke bestanden. Silverlight ondersteunt het werken met sockets. Op die manier is het mogelijk om via een TCP-connectie te communiceren met een andere entiteit, in ons geval de server. Het bereik van de poorten waarnaar geconnecteerd kan worden van in een Silverlight-applicatie is echter beperkt tot 4502-4534. Wanneer men dus een connectie zou willen opzetten naar een FTP-server, zouden we die server moeten configureren om ook te luisteren op een poort binnen dat bereik, in plaats van enkel op de standaard poort 21. De communicatie moet echter niet noodzakelijk gebeuren via FTP. Het zou ook mogelijk zijn om zelf een kleinere serverapplicatie te schrijven, met een veel beperktere functionaliteit dan FTP, die ook in staat is om via een sockets bytes te ontvangen en die op te slaan op de server. Deze applicatie zou dan vanzelfsprekend ook moeten luisteren op een van de toegestane poorten. Op deze manier is het niet nodig om zelf een volledige FTP-client te schrijven voor Silverlight, omdat enkel de functies die noodzakelijk zijn voor deze toepassing voorzien moeten worden. Silverlight biedt dus zeker en vast mogelijkheden aan om een uploadsysteem te bouwen dat aan onze vereisten voldoet.

6.1. UPLOAD

47

Java Applet Een standaard Java Applet is gebonden aan zekere beveiligingsbeperkingen. Zo is het niet mogelijk bibliotheken in te laden, of om toegang te krijgen tot lokale bestanden. Indien men niet gebonden wil zijn aan dergelijke beperkingen, moet men gebruik maken van een zogeheten vertrouwde Applet. Men kan een vertrouwde Applet genereren door de standaard Applet te ondertekenen met behulp van een private sleutel. Op die manier kan de ontwikkelaar ervan later worden geauthenticeerd aan de hand van zijn publieke sleutel. Binnen een vertrouwde Applet is het dan mogelijk om te werken met lokale bestanden zoals in een gewone desktopapplicatie. Bovendien kan men nu ook onbeperkt gebruik maken van de vele externe bibliotheken die beschikbaar zijn voor Java. Men kan dus een FTPbibliotheek gebruiken waarmee het transfereren van lokale bestanden naar een FTP-server erg eenvoudig wordt.

Keuze Van de hierboven besproken oplossingen blijken alleen een Silverlight toepassing of een Java Applet te voldoen aan onze vereisten. Ik heb besloten om voor ons systeem een Java Applet te ontwikkelen die instaat voor het uploaden van de bestanden. Deze keuze werd bepaald door verschillende elementen: • De rest van ons mediabeheersysteem werd ook ontwikkeld in Java. De keuze voor een Applet tegenover Silverlight lag dus iets meer voor de hand, aangezien we dan alles konden ontwikkelen binnen dezelfde omgeving (de Netbeans IDE). Bovendien was de leercurve voor het ontwikkelen van een Applet iets minder steil dan die zou geweest zijn voor het ontwikkelen voor een Silverlight-toepassing. • Door te werken met Java Applets kon ik een bestaande bibliotheek gebruiken om de bestanden te uploaden via FTP. Hierdoor kon ik zonder veel moeite gebruik maken van alle functionaliteiten van het FTP-protocol.

6.1.3

Finale versie: FTP upload via Applet

Voor de tweede en tevens laatste versie van het uploadsysteem is gekozen om te werken met een Java Applet. Via de Applet kan de gebruiker het gewenste mediabestand selecteren, dat vervolgens via FTP wordt ge¨ upload naar een FTP-server. Voor de FTP-functionaliteiten wordt gebruik gemaakt van de Apache Commons Net-bibliotheek [33], een onderdeel van het Apache Commons-project. Het doel van de Net-bibliotheek is om de globale functionaliteiten van verschillende internetprotocollen beschikbaar te maken via Java-objecten. De ondersteunde protocollen bevatten onder meer Telnet, POP3, SMTP, en dus ook FTP. Ook

6.1. UPLOAD

48

de passive mode van het FTP-protocol wordt volledig ondersteund, zodat die kan gebruikt worden om firewall-problemen aan de client-zijde te voorkomen.

Overzicht Uiteraard werd de structuur van het uploadsysteem grondig gewijzigd door het werken met een Applet. In Figuur 6.4 wordt de nieuwe structuur schematisch weergegeven.

Browser Aan de client-zijde is er nog steeds de browser, die een formulier weergeeft waarin de gebruiker een titel kan invullen voor het item dat hij wil toevoegen, eventueel nog aangevuld met een korte beschrijving. De formulier data wordt via een HTTP POST verzonden naar de UploadManager-Servlet.

UploadApplet De UploadApplet is nu de belangrijkste component aan de client-zijde. De gebruiker kan het mediabestand selecteren dat hij wenst toe te voegen aan het systeem. Vervolgens wordt dit bestand ge¨ upload naar de FTP-server. Tijdens de upload krijgt de gebruiker info over de status ervan. Een statusbalk duidt aan hoever de upload gevorderd is en ook de ogenblikkelijke uploadsnelheid wordt weergegeven. Er wordt ook een schatting getoond van de resterende uploadtijd. Eens het bestand volledig is ge¨ upload wordt de UploadManager hiervan op de hoogte gebracht door middel van een HTTP GET-boodschap. De Applet wordt vlak voor de uitvoering geconfigureerd aan de hand van enkele parameters. Dit zijn parameters in verband met de FTP-server (adres, poortnummer, logingegevens), het item (itemID) en de UploadManager (URL waarmee die bereikbaar is).

UploadManager De centrale klasse op de server is nu de UploadManager. De functionaliteit ervan is te vergelijken met de UploadServlet uit het eerste uploadsysteem. De UploadManager staat in voor het toevoegen van het item in het systeem en het up to date

Client

JApplet

Server UploadApplet

Browser

PUT file

notifyUploaded

FTPServer

UploadManager

POST title

Figuur 6.4: Overzicht uploadsysteem (versie 2)

HttpServlet

6.1. UPLOAD

49

houden van de informatie erover. Ook de acties die moeten ondernomen worden op het mediabestand, worden ge¨ınitieerd door de UploadManager

Scenario: ingest-procedure In Figuur 6.5 wordt een scenario weergegeven waarbij een gebruiker een nieuw bestand toevoegt aan het systeem. Hierin is te zien hoe het uploadsysteem interageert met de rest van het systeem. Een gebruiker kan een item toevoegen door in een formulier een titel in te vullen en dit te versturen naar de server (1). Het uploadsysteem zal daarop aan het itembeheersysteem vragen om een nieuw item aan te maken (2 en 3). Aan dat nieuwe item wordt reeds enkele informatie (titel, datum, organisatie...) toegevoegd (4) en het item wordt toegevoegd aan de databank (5). Hierbij wordt een uniek itemId gegenereerd waarmee men het item vanaf nu kan identificeren (6). Dit itemId wordt door het uploadsysteem gebruikt om een UploadApplet te configureren (7) alvorens die terug naar de gebruiker te sturen (8). Via de UploadApplet kan de gebruiker nu een bestand selecteren (9) dat wordt ge¨ upload naar de FTP-server (10). Wanneer het bestand volledig is ge¨ upload, wordt het uploadsysteem hiervan op de hoogte gebracht (11). Hierop zal het bestand verplaatst worden naar de juiste locatie op de schijf (12) en eens dat gebeurd is wordt via het mediabeheer deelsysteem informatie bekomen over het videobestand (13). Deze informatie wordt vervolgens toegevoegd aan het item (15). Het itembeheersysteem zorgt ervoor dat deze nieuwe informatie ook persistent wordt via de databank (16). Tenslotte zal het uploadsysteem er nog voor zorgen dat er keyframes worden gegenereerd (17), evenals een lageresolutieversie (19).

Applet ondertekenen Zoals reeds aangehaald in 6.1.2 kan alleen een vertrouwde applet toegang krijgen tot lokale bestanden. Die toegang zal pas verleend worden als de gebruiker onze handtekening aanvaardt (Figuur 6.6). De procedure voor het ondertekenen van een Applet is vrij eenvoudig. Vooreerst dient men de gecompileerde Applet toe te voegen aan een JAR-bestand (Java Archive). Daarna moet men een sleutelpaar genereren met bijhorend certificaat voor de publieke sleutel. Hiervoor kan men gebruik maken van keytool, een commandolijnprogramma dat onderdeel is van de Java Developement Kit (JDK). Aan de hand van dit sleutelpaar kan men vervolgens het JAR-bestand handtekenen met behulp van jarsigner. Deze stappen zijn samengevat in onderstaand codefragment: javac UploadApplet.java jar cvf UploadApplet.jar UploadApplet.class keytool -genkey -alias UploadApplet -validity 365 jarsigner UploadApplet.jar UploadApplet

6.1. UPLOAD

50

uploadsystem User

itemmanagement

mediamanagement

1: add item 2: create item 3: new Item 4: setItemInfo

6: itemId

5: persistItem

7: configure UploadApplet

8: UploadApplet 9: select file

10: upload file to FTP server 11: notify uploaded 12: move file 13: get video info 14: video info 15: update item 16: update DB

loop [every 10 seconds] 17: generate keyframe

18: start FFmpeg proces

19: generate low resolution version 20: start FFmpeg proces

Figuur 6.5: Scenario: toevoegen van een item

6.2. MEDIA OPERATIES

51

Om de Applet op te nemen in onze webpagina wordt de volgende HTML-code gebruikt: <param name="serverAddress" value="10.247.35.17" /> <param name="serverPort" value="2100" /> <param name="itemID" value="85" /> <param name="succesURL" value=":7080/Ingest/UploadManager" /> Binnen het archive-attribuut van het applet-element is ook nog de Net-bibliotheek opgenomen. Deze bibliotheek is namelijk, zoals eerder vermeld, noodzakelijk voor de FTPfunctionaliteit in de Applet. In Figuur 6.7 is te zien hoe de Applet eruit ziet tijdens het uploaden van een bestand.

6.2 6.2.1

Media operaties Keyframe-extractie

Na het uploaden worden onmiddellijk enkele keyframes gegenereerd. Ik heb er voor gekozen om iedere 10 seconden een keyframe te genereren. Er zijn vanzelfsprekend intelligentere manieren mogelijk om de keyframes te genereren. Het zou bijvoorbeeld interessant zijn om voor iedere scene of ieder shot in het videofragment het meest representatieve frame te nemen als keyframe. Hiervoor zou echter meer gespecialiseerde software nodig zijn en aangezien dit buiten het kader van dit werk viel, heb ik het bij de eenvoudige strategie gehouden. Aan de hand van deze keyframes is het reeds mogelijk om de gebruiker een ruim overzicht te geven van de visuele inhoud van het videobestand. De afmetingen van de keyframes worden zo bepaald dat de langste zijde (dit zal doorgaans de breedte zijn) gelijk is aan 120 pixels, zonder dat de breedte-hoogte-verhouding gewijzigd wordt.

6.2.2

Generatie van een lageresolutieversie

Er wordt ook al direct een lageresolutieversie gegenereerd na het uploaden. Deze versie zal de volgende eigenschappen hebben: • De langste zijde van de video wordt herschaald naar 320 pixels • De framerate wordt ingesteld op 15 frames per seconde • De audio bitrate wordt ingesteld op 32 kilobits per seconde


Figuur 6.6: Toestemming is vereist voor uitvoering vertrouwde Applet

Figuur 6.7: UploadApplet tijdens uploaden bestand

52


53

• Het formaat dat gebruikt wordt is FLV (Flash Video) Op deze manier wordt de bestandsgrootte van het videobestand voldoende gereduceerd, terwijl de kwaliteit aanvaardbaar blijft. Doordat de video omgezet wordt naar het FLV-formaat is het mogelijk om deze versie af te spelen met behulp van een Flex-videospeler binnen de browser.

54

Hoofdstuk 7 Metadatabeheer In moderne IT-gebaseerde productieomgevingen, speelt metadata een belangrijke rol. Metadata is als het ware de lijm die de verschillende onderdelen van het productieproces met elkaar verbindt. Ten eerste wordt metadata gebruikt voor de beschrijving van de mediabestanden. Deze beschrijving kan gaan over de inhoud (waarover gaat het fragment?), maar ook over de context (waar en wanneer opgenomen, wie zijn de medewerkers, is dit fragment gerelateerd aan andere?). Aan de hand van deze beschrijving is het dan mogelijk om later de bestanden terug te vinden. Het is dus aangeraden om beschrijvingen te gebruiken die zo accuraat mogelijk zijn, zodat het bestand in de juiste gevallen wordt teruggevonden. Daarenboven wordt metadata ook gebruikt voor het documenteren van de digitale rechten die op de bestanden rusten. Het is belangrijk om over de juiste documentatie van die rechten te beschikken, aangezien die aangeven binnen welke context de bestanden wel en niet mogen gebruikt worden. In dit hoofdstuk wordt besproken op welke manier het gebruik van metadata is ge¨ıntegreerd in het mediabeheersysteem. Eerst komt het gebruikte metadataschema aan bod en daarna wordt bekeken hoe de use case die besproken werd in 5.1.2 wordt ge¨ımplementeerd. Er wordt besproken op welke manier de metadata nu precies wordt aangewend om het systeem te doorzoeken, en hoe de gebruiker in staat wordt gesteld om de metadata van een item aan te passen.

7.1

Metadatamodel

Wanneer men werkt met grote hoeveelheden metadata, is het belangrijk dat men beschikt over een goed metadatamodel. Een dergelijk metadatamodel beschrijft welke elementen er gebruikt worden voor het beschrijven van een item, en wat de relatie is tussen die elementen. Daarnaast wordt er ook een syntax en eventueel een vocabularium vastgelegd, zodanig dat communicatie tussen verschillende partijen mogelijk is aan de hand van het metadatamodel.

7.1. METADATAMODEL

55

Een goed metadatamodel zal in staat zijn om items nauwkeurig te beschrijven

7.1.1

EBU Core

Er zijn verschillende metadatamodellen voorhanden. Elk van deze modellen heeft zijn vooren nadelen, en zijn eigen toepassingsgebieden. In het ontwikkelde mediabeheersysteem wordt gebruik gemaakt van het EBU Core formaat [34]. Dit is een formaat ontwikkeld door de European Broadcasting Union (EBU). Het oorspronkelijk doel was om een gemeenschappelijke, bondige verzameling van informatie te definiëren, via dewelke media-archieven doorzocht zouden kunnen worden. De EBU Core Metadata Set is opgebouwd als een verfijning van Dublin Core [35], een veel gebruikte standaard voor het beschrijven van materiaal uit verschillende domeinen. Het is een minimum lijst van attributen waarmee men een media-item kan karakteriseren. De basiselementen bevatten elementen die de inhoud van het item beschrijven, zoals Title, Description, Subject en Type. Daarnaast zijn er ook enkele elementen die verscheidene entiteiten (persoon, groep van personen of organisatie) binnen het productieproces identificeren. Voorbeelden hiervan zijn Creator, Publisher, Contributor en Metadata Provider. De verschillende Date elementen en Publication History bevatten informatie over de geschiedenis van het item. Een uitgebreide beschrijving van de verschillende elementen uit de EBU Core specificatie is te vinden in Bijlage B. Er zijn nog heel wat alternatieven voor de beschrijving van de metadatabeschrijving. Voorbeelden hiervan zijn MPEG-21 [36], EBU P/META [37], NewsML-G2 [38] en SMPTE Metadata [39]. De reden waarom er gekozen wordt voor het EBU Core-formaat, is dat dit een formaat is waarmee men media-items nauwkeurig kan beschrijven, maar dat toch overzichtelijk is en snel aan te leren, in tegenstelling tot sommige van de eerder vermelde alternatieven.

7.1.2

Opslag van de metadata

De specificatie van de EBU Core Metadata Set bevat een XML-schema waarin alle elementen uitgebreid beschreven zijn. Uit dit schema is eenvoudig af te leiden welke velden er allemaal moeten voorzien zijn om de metadata bij te houden. Om de metadata dan effectief persistent bij te houden zijn er verschillende mogelijkheden. De opties die overwogen werden zijn de volgende: 1. Voor ieder item wordt een afzonderlijk XML-bestand bijgehouden. Dit bestand voldoet aan het EBU Core XML-schema en bevat de metadata die hoort bij het item. Het bestand wordt opgeslagen ergens in het bestandssysteem (bijvoorbeeld op dezelfde locatie als het beschreven mediabestand) en er wordt naar die locatie verwezen vanuit de databank.

7.1. METADATAMODEL

56

2. Idem als de vorige optie, maar de XML-data wordt nu opgeslagen in de databank, samen met de andere informatie over het item. 3. Alle elementen uit het XML-schema worden vertaald naar tabellen in de databank. De metadata wordt bewaard in die tabellen. Op het eerste zicht lijken de eerste twee opties een onnodige overhead met zich mee te brengen. De XML-data die opgeslagen wordt bevat immers steeds de namen van de elementen die voorkomen (de tags), en dit voor ieder item. Daartegenover staat dat er bij de derde optie doorgaans veel velden leeg zullen blijven in de databanktabellen, aangezien de meeste velden optioneel zijn. In de XML-documenten worden de niet-beschikbare velden eenvoudigweg niet opgenomen (Figuur 7.1). Een andere belangrijke vereiste is dat de metadata snel en eenvoudig doorzoekbaar is. Wanneer XML-data zou worden bewaard in afzonderlijke bestanden kan niet aan die vereiste voldaan worden. Men is dan immers genoodzaakt om steeds sequentieel die afzonderlijke bestanden te doorzoeken. In het geval dat de metadata bewaard wordt in afzonderlijke databanktabellen, kan het zoeken vrij eenvoudig gebeuren indien men wil zoeken op basis van één enkele element, aangezien men dan slechts één tabel moet bevragen. Wanneer er echter meerdere elementen betrokken zijn in de zoekopdracht, bijvoorbeeld bij een full text search, wordt de bevraging erg complex, en de vele JOIN -operaties die nodig zijn zullen de snelheid negatief be¨ınvloeden. Wanneer de XML-data nu bewaard wordt in een aparte kolom binnen de reeds bestaande item-tabel wordt alles een stuk eenvoudiger. Er is nu slechts één tabel die dient doorzocht te worden. Bovendien zijn er sinds MySQL versie 5.1.5 twee functies beschikbaar die het werken met XML-data binnen een MySQL-databank veel eenvoudiger maken. De interessantste functie is ExtractValue. Deze functie verwacht enerzijds de naam van een kolom die XML-data bevat, en anderzijds een XPath-expressie die gebruikt wordt om een gedeelte van die XML-data te selecteren. Als deze functie gebruikt wordt in de WHEREclause van onze database query wordt het zoeken binnen de metadata erg eenvoudig, zoals (a) XML fragment (enkel de beschikbare velden worden opgenomen) <ebucore:title typeLabel="news"> Journaal 14/05

(b) Databank record (veel null waarden)

dŝƚůĞ ƚŝƚůĞ

:ŽƵƌŶĂĂů ϭϰͬϬϱ

ůĂŶŐ

ŶůͲďĞ

ƚǇƉĞ

ŶĞǁƐ

ƐƚĂƚƵƐ

ŶƵůů

ƐƚĂƌƚ ĚĂƚĞ

ŶƵůů

ĞŶĚĚĂƚĞ ŶƵůů

Figuur 7.1: Overhead bij opslag metadata

ƉĞƌŝŽĚ ŶƵůů

7.2. INTERACTIE VAN DE GEBRUIKER MET DE METADATA

57

aangetoond wordt in onderstaand fragment: SELECT itemID FROM items WHERE ExtractValue(metadata,"//dc:title") LIKE "%zoekterm%"; Deze query zal alle items vinden waarvan de titel voldoet aan de zoekterm. Ik heb dus voor deze toepassing de tweede optie gekozen omdat het doorzoeken van de metadata op die manier eenvoudig kan gebeuren. Wanneer het aantal items in het systeem groter wordt zal de snelheid van zoeken hierdoor echter negatief be¨ınvloed worden, aangezien het niet mogelijk is om een index aan te maken voor een knoop binnen de XML-data. Het zou daarom beter zijn om hiervoor gebruik te maken van een gespecialiseerde zoekmachine. Een voorbeeld van een dergelijke zoekmachine is Apache Lucene [40]. Lucene is een open source Java-bibliotheek waarmee het mogelijk is om erg efficiënt tekstuele informatie te doorzoeken. Lucene gebruikt daarvoor een ge¨ınverteerde index [41] , een erg snelle manier om aan de hand van zoektermen documenten terug te vinden. In het geval van ons systeem zouden die documenten dan de metadata bevatten, in XML-formaat. Het zoeken met behulp van Lucene is momenteel nog niet ge¨ıntegreerd in het mediabeheersysteem aangezien de tijd daarvoor ontbrak, dus voorlopig wordt de metadata opgeslagen in de bestaande MySQL-databank. Het integreren van een Lucene-zoeksysteem zou echter een interessante uitbreiding zijn.

7.2

Interactie van de gebruiker met de metadata

Nu gekend is op welke wijze de metadata zal worden bijgehouden, kan er worden gekeken hoe deze metadata wordt aangewend om de use case uit 5.1.2 te verwezenlijken. Eerst wordt besproken hoe een gebruiker items kan terugvinden door te zoeken op basis van metadata informatie. Vervolgens ga ik dieper in op de manier waarop een gebruiker de beschikbare metadata kan raadplegen, wijzigen of verwijderen.

7.2.1

Doorzoeken van het systeem op basis van metadata

Om de mediadatabank te doorzoeken naar items, is het systeem uitgerust met een SearchServlet. Deze werd al even kort aangehaald in 5.2.2, maar hier wordt dieper ingegaan op de manier waarop de Search Servlet zoekt op basis van metadata. De eenvoudigste manier om een item op te zoeken is via een full text search: de gebruiker geeft één (of meerdere) woord(en) op, en alle items die op één of andere manier verwant zijn met dat woord (die woorden) worden teruggegeven. Om dit te verwezenlijken wordt de XPath expressie //* gebruikt als tweede argument van de ExtractValue functie. Deze expressie selecteert alle knopen in het document, onafhankelijk van hun plaats of naam. De query die uitgevoerd wordt op de databank is dan de volgende:


58

SELECT itemID FROM items WHERE ExtractValue(metadata,"//*") LIKE "%zoekterm%"; Wanneer men meer gedetailleerd te werk wil gaan, kan men de zoekterm verder preciseren, en op meer specifieke eigenschappen zoeken. Zo kan men bijvoorbeeld zoeken op de titel van een item, op een persoon die te zien is in een item, of op een organisatie die verantwoordelijk is voor de publicatie van een item. Hiervoor volstaat het om middels een correcte XPathexpressie de gewenste knopen te selecteren, en de waarde ervan te vergelijken met de zoekterm. Het is ook mogelijk om te zoeken op meer contextuele informatie, zoals de periode waarin het item gecreëerd is, of de locatie waar het videofragment is opgenomen. Deze laatste informatie zal echter niet altijd beschikbaar zijn, waardoor de lijst van resultaten niet altijd compleet zal zijn. De Search-Servlet geeft als resultaat steeds een XML-geformatteerde lijst weer die enkele basisgegevens over de gevonden items bevat. Op die manier is het mogelijk dat ook externe toepassingen gebruik maken van deze Servlet om het systeem te doorzoeken, door de juiste parameters door te geven via een HTTP GET-methode: http://[server]/Search?fullText=fortis&title=journaal Een mogelijke uitbreiding zou zijn om de zoekresultaten te laten afhangen van het profiel van de gebruiker. Een sportjournalist zal immers doorgaans in andere items ge¨ınteresseerd zijn dan een politiek verslaggever, ook al gebruiken beiden exact dezelfde zoekopdracht. Men zou er hier dan voor kunnen opteren om de irrelevante items achterwege te laten, of om de relevante items een grotere prioriteit te geven zodat die prominenter aanwezig zijn in het zoekresultaat. De gebruikers van het systeem zouden dan kunnen aangeven welk soort items voor hen het meest interessant zijn, daarbij startend van een standaardlijst op basis van hun functie binnen de organisatie. Om dit systeem naar behoren te laten werken, zou er veel aandacht moeten besteed worden aan het aanduiden van het type dat bij een toegevoegd item hoort.

7.2.2

Toevoegen, bewerken en verwijderen van metadata

In het vorig onderdeel werd besproken hoe items kunnen teruggevonden worden op basis van de metadata die beschikbaar is. In wat nu volgt wordt behandeld hoe die metadata kan worden toegevoegd aan een item.

XMLBeans Aangezien de metadata uiteindelijk zal worden opgeslagen in XML-formaat, moet deze dus ook als dusdanig worden geformatteerd. Er moet een XML-document aangemaakt worden, waaraan stelselmatig knopen worden toegevoegd. Java biedt hiervoor de Java API for


59

XML Processing (JAXP) [42] aan waarmee het mogelijk is om te interageren met XMLdocumenten. Wanneer men echter te maken heeft met grotere documenten, met een vrij complexe structuur, wordt deze manier van werken nogal omslachtig. Daarom heb ik gebruik gemaakt van XMLBeans [43]. XMLBeans is een technologie die het mogelijk maakt om te interageren met XML-documenten via Java objecten. Op basis van een XML-schema genereert de XMLBeans compiler een verzameling van Java klassen en interfaces die de types voorstellen die gebruikt worden binnen het XML-schema (zie Figuur 7.2). Op die manier wordt het mogelijk om te interageren met de instanties van het betreffende schema via de get- en set-methoden van die gegenereerde Java-klassen. Er worden ook methodes voorzien om nieuwe kind elementen toe te voegen aan een bepaalde knoop, of om bepaalde kinderen van een knoop te verwijderen. Wanneer de metadata van een item zal worden aangepast wordt eerst de bestaande XMLtekst die zich in de databank bevindt geparsed naar de overeenkomstige Java-objecten. Op deze objecten kunnen de gewenste operaties worden uitgevoerd, en achteraf kan de ge¨ updatete XML bekomen worden aan de hand van de xmlText-methode van het root-element. Deze ge¨ updatete XML wordt dan opnieuw opgeslagen in de databank.

Automatische generatie van invulformulieren Om de gebruiker toe te laten metadata toe te voegen, moeten er HTML-invulformulieren voorzien worden waar de gegevens kunnen ingevuld worden. Gezien de omvang van de EBU Core Metadata Set, is het niet zinvol om al deze formulieren elk afzonderlijk hard te coderen. Dit zou niet enkel veel werk met zich meebrengen, maar ook het risico vergroten dat er bepaalde elementen vergeten worden. Bovendien zou een geringe wijziging in het schema er mogelijks toe leiden dat al deze formulieren opnieuw moeten gecodeerd worden. Daarom werd er gezocht naar een manier om de invulformulieren automatisch te genereren, op basis van het XML-schema dat de EBU Core specificatie beschrijft. Eerst werd overwogen om een XSLT-transformatie uit te voeren op het XML-schema, om aldus verschillende HTML-pagina’s te genereren die de juiste invulvelden bevatten. Het bleek echter al snel dat deze transformatie erg complex zou worden door de grote hoeveelheid verschillende datatypes die waren gedefinieerd binnen de EBU Core specificatie. Bovendien bevat het XML-schema enkele subtiliteiten, zoals uitbreidingen of beperkingen van basistypes, die de transformatie nog wat ingewikkelder zouden maken. Aangezien de XMLBeans-compiler reeds komaf maakt met een groot deel van deze problemen bij de generatie van de Java-klassen, heb ik besloten deze gegenereerde klassen te gebruiken bij het aanmaken van de invulformulieren. De invulformulieren worden nu gegenereerd door toepassing van reflectie op de XMLBeans-klassen. Via reflectie is het mogelijk om gedurende de uitvoering van een programma eigenschappen af te leiden over de structuur en het gedrag van bepaalde klassen en objecten. Wanneer dit principe wordt toegepast op


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="adres"> <xs:complexType> <xs:sequence> <xs:element name="straat" type="xs:string"/> <xs:element name="nummer" type="xs:string"/> <xs:element name="postcode" type="xs:string"/> <xs:element name="gemeente" type="xs:string"/>

yD>ĞĂŶƐ ŽŵƉŝůĞƌ

public interface Adres extends org.apache.xmlbeans.XmlObject { String getStraat(); void setStraat(String straat); String getNummer(); void setNummer(String nummer); String getPostcode(); void setPostcode(String postcode); String getGemeente(); void setGemeente(String gemeente); }

Figuur 7.2: Omzetting van XML-schema naar Java Interface (vereenvoudigd)

60


61

de XMLBeans-klassen, is het mogelijk om de structuur van de metadata in kaart te brengen. Door na te gaan welke methoden er zijn om knopen toe te voegen, kan men dynamisch bepalen welke metadata waar mag (of moet) toegevoegd worden. Voor elk van de 18 basiselementen uit het schema wordt een formulier gegenereerd. Het genereren van een dergelijk formulier is een recursief proces. Er wordt gestart met het basiselement. Aan de hand van de methoden die men kan uitvoeren op dit element wordt bepaald welke de kindknopen zijn van het element. Het return type van deze methoden vertelt van welke aard die kindknopen zijn. Wanneer de complexiteit van dit type beperkt is (zoals bij een datum, een entiteit, een tekstuele waarde) wordt de beschouwde kindknoop op gepaste wijze rechtstreeks opgenomen in het formulier. Voor andere, complexere types wordt een nieuwe iteratie gestart waarbij deze kindknoop verder ontleed wordt. Dit proces gaat voort tot het basiselement is herleid tot eenvoudige kindknopen die kunnen worden opgenomen in het formulier. In Figuur 7.3 wordt dit schematisch voorgesteld. De manier waarop elementen worden opgenomen in het formulier is afhankelijk van het type. Wanneer dit type bijvoorbeeld een datum is, komt in het formulier een tekstueel invoerveld, met daaraan een datepicker verbonden, die de gebruiker toelaat om op een grafische manier een datum te selecteren. Wanneer een afmeting moet worden ingevuld, komt in het formulier een tekstbox met daarnaast een dropdownlist waaruit de gebruiker een keuze kan maken voor de eenheid waarin de afmeting is uitgedrukt. Op die manier worden alle elementen vertaald naar een HTML-invoerveld, of een combinatie van meerdere invoervelden. Het label dat bij een dergelijk invoerveld komt, wordt afgeleid uit de bijhorende methodenaam. De methode setEmailAddress bijvoorbeeld zal leiden tot een invoerveld met bijhorende label Email Address. Wanneer één van de 18 mogelijke invulformulieren door de gebruiker verzonden wordt naar de server, is het de bedoeling dat dit volledig automatisch verwerkt wordt, onafhankelijk van het type formulier. Ook dit gebeurt via reflectie. Dit wordt bekomen door de invoervelden een gepaste naam te geven. Deze naam is een aaneenschakeling van de namen van de methodes die achtereenvolgens moeten worden uitgevoerd om de ingevulde metadata op de correcte plaats in te voegen in het metadatadocument (Tabel 7.1). Op die manier kan de Servlet die instaat voor het verwerken van de formulierinformatie, de ontvangen metadata correct toevoegen.

Methode

setFamilyName

Label

Family Name

Invoerveld name

addNewPublisher.addNewContactDetails.addNewName.setFamilyName

Tabel 7.1:


Start

Start with base element

Get next method of form setXXX or addNewXXX

XXX = supported type?

NO

Start new iteration with XXX as base element

YES

Generate formelement for type XXX

YES

Other methods available?

When finished: continue parent iteration

NO

Return

Figuur 7.3: Automatische generatie van invulformulieren

62


63

Het aanpassen van reeds beschikbare metadata verloopt op een nagenoeg identieke wijze. Het enige verschil is dat de invoervelden nu reeds ingevuld worden, wanneer de betreffende metadata beschikbaar is. Ook het achterhalen of de metadata al dan niet beschikbaar is gebeurt via reflectie. In het XML-schema dat de EBU Core specificatie beschrijft, is naast de structuur van de metadata ook documentatie te vinden over de verschillende elementen. Deze informatie is opgenomen binnen verschillende documentation-tags. XMLBeans zorgt ervoor dat deze informatie ook via Java beschikbaar is. Deze informatie wordt dan ook samen met het formulier getoond aan de gebruiker, zodanig dat die meer duidelijkheid krijgt over de precieze betekenis van de verschillende invoervelden.

64

Hoofdstuk 8 Gebruikersinterface In de vorige hoofdstukken werd de werking van het mediabeheersysteem aan de server-zijde besproken. In dit hoofdstuk wordt nu beschreven hoe dit alles in de browser wordt gepresenteerd aan de gebruiker.

8.1

Registratie

Alvorens een gebruiker kan interageren met het systeem, moet hij zich registreren. Hij kan dit doen door een registratieformulier in te vullen. Eerst wordt er persoonlijke informatie over de gebruiker gevraagd (Figuur 8.1). Wanneer de gebruiker het formulier tracht te verzenden, wordt de ingevulde data eerst gevalideerd. Pas wanneer alle informatie correct is ingevuld kan de gebruiker voortgaan met de tweede stap van de registratie (Figuur 8.2). Hier kan de gebruiker informatie verschaffen over de organisatie waarvoor hij werkt. Wanneer ook deze gegevens correct worden ingevuld worden de gebruikersgegevens toegevoegd aan de databank (Figuur 8.3). Vooraleer de gebruiker nu echt met het systeem kan werken, dient hij eerst nog zijn account te activeren door middel van een link die hem wordt toegestuurd via het opgegeven emailadres. Op die manier is men zeker dat de gebruiker een geldig adres heeft opgegeven.

8.2

Aanmelden bij het systeem

Eens de gebruiker zijn account geactiveerd heeft, kan hij zich aanmelden bij het systeem (Figuur 8.4). Wanneer de gebruiker de correcte aanmeldgegevens invult krijgt hij het overzichtscherm te zien met bovenaan een menu (Figuur 8.5). De gebruiker kan in dat menu selecteren welke actie hij wil uitvoeren. De belangrijkste van deze acties worden in de volgende secties besproken.

8.2. AANMELDEN BIJ HET SYSTEEM

Figuur 8.1: Registratieformulier: persoonlijke informatie

Figuur 8.2: Registratieformulier: informatie over organisatie

Figuur 8.3: Voltooiing van het registratieproces

65

8.3. NIEUW ITEM TOEVOEGEN

66

Figuur 8.4: Aanmeldscherm

Figuur 8.5: Welkomscherm met menu

8.3

Nieuw item toevoegen

Wanneer de gebruiker een nieuw item wil toevoegen, krijgt hij een scherm te zien zoals in Figuur 8.6. Er zijn 4 tabbladen te zien zodat de verschillende stappen die een gebruiker kan ondernemen bij het toevoegen van een nieuw item duidelijk te zien zijn. In het begin zijn slechts de eerste 2 tabbladen actief. Via Manual info kan de gebruiker een titel en een beschrijving invullen voor het toe te voegen item. Wanneer er echter reeds een XML-bestand beschikbaar is dat EBU Core-metadata bevat, kan de gebruiker opteren om dit bestand te uploaden. Deze metadata wordt dan onmiddellijk toegevoegd aan het item. Wanneer de gebruiker via één van deze opties de initiële info toevoegt worden de 2 laatste tabbladen actief. Bij Upload file wordt nu de Applet geladen die gebruikt wordt om een bestand te uploaden (Figuur 8.7). Terwijl het bestand aan het uploaden is, kan de gebruiker ervoor opteren om via Edit metadata al te starten met het aanpassen van de metadata. Om dit alles in verschillende tabbladen weer te geven, wordt gebruik gemaakt van de Tabs-component van het jQuery UI Framework. Deze component maakt het mogelijk om met erg weinig code de inhoud van een webpagina weer te geven in verschillende tabbladen.

8.4

Doorzoeken van het systeem

Wanneer de gebruiker het systeem wil doorzoeken, krijgt hij initieel slechts één enkel tekstvak te zien waarin hij zijn zoekterm kan opgeven (Figuur 8.8). Dit tekstvak wordt gebruikt voor de full text search. Wanneer de gebruiker zijn zoekopdracht verder wil specifiëren, kan hij kiezen voor het tabblad Advanced search, en daar meer details opgeven.

8.4. DOORZOEKEN VAN HET SYSTEEM

Figuur 8.6: Toevoegen van item

Figuur 8.7: Toevoegen van item: uploaden van media bestand

67

8.5. DETAILOVERZICHT VAN ITEM

68

Deze zoekopdracht wordt via Ajax asynchroon verzonden naar de Search-Servlet op de server. Indien er items gevonden worden die aan deze zoekopdracht voldoen, wordt een lijst met deze resultaten weergegeven. Voor elk van de gevonden items wordt een bondig overzicht getoond, met onder andere de titel van het item, en de datum waarop het werd toegevoegd. Als er voor dat item reeds een videobestand werd ge¨ upload, zal er ook een keyframe worden opgenomen in het overzicht. Wanneer de gebruiker daarop klikt, zal het detailoverzicht van het betreffende item worden weergegeven.

8.5

Detailoverzicht van item

In Figuur 8.9 is te zien wat de gebruiker te zien krijgt wanneer hij een detailoverzicht van een item opvraagt. Enerzijds krijgt de gebruiker een tekstueel overzicht van de beschikbare metadata (titel, omschrijving, datums...), maar anderzijds krijgt de gebruiker ook een grafisch overzicht van de inhoud van het vidoefragment (indien dat beschikbaar is). Dit wordt verwezenlijkt op 2 manieren. Ten eerste is er een videospeler waarin een lageresolutieversie van het fragment afspeelt. Deze videospeler is ontwikkeld met behulp van Flex. De gebruiker kan via de voortgangsbalk navigeren door de video. Ten tweede is er ook een overzicht van keyframes die beschikbaar zijn voor het videofragment. Deze keyframes worden weergegeven onder de videospeler, en met behulp van het scrollwieltje van de muis kan er gebladerd worden door deze keyframes. Wanneer de gebruiker klikt op één van deze keyframes wordt er in videospeler gesprongen naar de overeenkomstige positie. Dit is mogelijk door gebruik te maken van de Flex Ajax Bridge (FABridge). De FABridge is een kleine bibliotheek die men kan gebruiken binnen een Flex-applicatie, en die het mogelijk maakt om met de Flex-applicatie te communiceren via JavaScript-functies binnen dezelfde webpagina. Klikken op een keyframe zorgt ervoor dat de JavaScript-functie videoSeek wordt uitgevoerd. De FABridge zal dit vertalen naar het uitvoeren van de videoSeek -functie in de Flex-applicatie. Indien er een mediabestand beschikbaar is, kan de gebruiker dit via deze pagina downloaden.

8.6

Bewerken van metadata

In Figuur 8.10 is een voorbeeld te zien van een invulformulier om de metadata te bewerken. Dit formulier werd automatisch gegenereerd op basis van het EBU Core XML-schema, zoals besproken in hoofdstuk 7. Om het formulier overzichtelijk te houden worden niet onmiddellijk alle invoervelden weergegeven. De invoervelden worden automatisch gegroepeerd in verschillende categoriën, en men kan een dergelijke categorie in- of uitklappen door op de naam ervan te klikken.

8.6. BEWERKEN VAN METADATA

Figuur 8.8: Doorzoeken van het systeem

Figuur 8.9: Detailoverzicht van item

69


70

Wanneer in dit formulier een datum moet ingevuld worden, kan dit door deze te selecteren met behulp van een Datepicker -component (Figuur 8.11). Deze component is een onderdeel van het jQuery UI Framework, en zorgt ervoor dat de datum steeds op een uniforme manier wordt geformatteerd. De Datepicker-component verschijnt automatisch wanneer een invoerveld voor een datum geselecteerd wordt. Naast de inputvelden wordt een beschrijving gegeven van de betekenis van de metadata. Ook deze beschrijving werd uit het EBU Core XML-schema gehaald.


Figuur 8.10: Bewerken van metadata

Figuur 8.11: Selecteren van datum via Datepicker-component

71

72

Hoofdstuk 9 Besluit In dit werk werd de ontwikkeling van een nieuw mediabeheersysteem met basisfunctionaliteiten voorgesteld. Op basis van de vereisten voor een dergelijk systeem, werd een architectuur voor het systeem uitgewerkt. Gebruikers kunnen met dit systeem interageren door enkel gebruik te maken van een webbrowser. Bij de ontwikkeling werd er dan ook gestoten op de limieten van de hedendaagse browsers. Daarbij is het immers niet mogelijk om via de traditionele manier bestanden groter dan 2 gigabyte te uploaden, wat voor het ontwikkelde systeem onontbeerbaar was. Daarom werd een oplossing uitgewerkt die gebruik maakt van een Java Applet voor de upload-functionaliteit. Er werd getracht om de gebruikersinterface zo intu¨ıtief mogelijk te maken, en er bovendien voor te zorgen dat de gebruiker een rijke ervaring kreeg bij het werken met het systeem. Hiervoor werden enkele technologieën voor het ontwikkelen van Rijke Internet Applicaties onderzocht. Uiteindelijk werd jQuery gebruikt, een JavaScript-framework dat onder andere het gebruik van Ajax in een webapplicatie eenvoudiger maakt. Daarbovenop werd met behulp van Flex een videospeler ontwikkeld die het mogelijk maakt om binnen de browser de lageresolutieversies van de video’s in het systeem te bekijken. Bij de ontwikkeling van het systeem werd ervoor gezorgd dat de verschillende componenten waaruit het systeem is opgebouwd zoveel mogelijk onafhankelijk zijn van elkaar. Op deze manier is het eenvoudig om bestaande componenten te vervangen door andere of om nieuwe componenten toe te voegen om de functionaliteit van het systeem uit te breiden. Het systeem zou dus kunnen gebruikt worden in enkele kleinere onderzoeks- en testprojecten, waar men in staat wil zijn om zonder veel moeite het systeem aan te passen. Het systeem dat werd ontwikkeld kan de basisfunctionaliteiten van een mediabeheersysteem vervullen, maar er kunnen vanzelfsprekend nog heel wat uitbreidingen worden toegevoegd. Zo is op dit moment geen component aanwezig die instaat voor het beheer van de auteursrechten die mogelijk rusten op de media-items. Wanneer men een mediabeheersysteem in een echte productieomgeving wil gebruiken, is dit echter een onmisbare component. Het

73 toevoegen van een dergelijke component zou dus een eerste interessante uitbreiding zijn. Daarnaast zou het ook interessant zijn om te onderzoeken op welke manier men het systeem beter doorzoekbaar kan maken. Op dit moment wordt de metada die men wenst te doorzoeken opgeslagen in een relationele databank, die niet geoptimaliseerd is voor het zoeken van XML-data. Het invoegen van een geoptimaliseerde zoekmachine in het systeem zou ervoor zorgen dat het systeem ten alle tijde snel doorzoekbaar blijft, ook wanneer er grote hoeveelheden items worden toegevoegd. Een andere mogelijke uitbreiding heeft te maken met de overgang tussen het bestaande Ardome-systeem, het nieuw ontwikkelde systeem. Het kan wellicht interessant zijn om de items die zich nu reeds in de Ardome-databank bevinden op een automatische manier te transfereren naar het nieuwe systeem, zodat men ook in het nieuwe systeem gebruik kan maken van het omvangrijke media-archief dat reeds voorhanden is. Het besluit is dan ook dat het ontwikkelde systeem reeds bruikbaar is voor basistoepassingen, en dat er voldoende mogelijkheden zijn om het systeem in de toekomst nog uit te breiden.

74

Bijlage A Technologiekeuzes Voor het begin van de eigenlijke ontwikkeling van het nieuwe mediabeheersysteem, moesten enkele beslissingen genomen worden in verband met de gebruikte techonologieën. In deze bijlage wordt kort overlopen welke technologieën uiteindelijk gebruikt werden en wat de reden hiervoor is.

A.1

Webserver

Het is van in het begin de bedoeling geweest om een webapplicatie te ontwikkelen, en dus geen desktoptoepassing. Hiervoor is er uiteraard een webserver nodig. Op wp3develop, de Linux-machine waarop de webapplicatie uiteindelijk zal draaien, is reeds een een webserver ge¨ınstalleerd. Het gaat hier om de recentste versie van Apache Tomcat (versie 6.0.18) [44]. Apache Tomcat is een servletcontainer, dit wil zeggen dat het mogelijk is om met Tomcat Java Servlets en JavaServer Pages (JSP) uit te voeren. Het Java-platform biedt heel wat mogelijkheden, en was bovendien het platform waar ik het meeste ervaring mee had. Java leek dus een geschikte keuze om het mediabeheersysteem te ontwikkelen. Ook de Tomcatserver leek geschikt om de webapplicatie te draaien, gezien de server in de loop van zijn bestaan al bewezen heeft een degelijke server te zijn. Daarom werd beslist niet op zoek te gaan naar een andere server, maar om te werken met de beschikbare Tomcat-server. De configuratie van de Tomcat-server kan gebeuren via een webinterface, maar ook met behulp van XML-configuratiebestanden. De webapplicatie wordt ontwikkeld binnen de Netbeans IDE [45]. Hiermee is het mogelijk om de applicatie lokaal te testen op een ge¨ıntegreerde Tomcat-server. Om de uiteindelijke webapplicatie dan beschikbaar te maken op wp3develop volstaat het om deze te compileren tot een WAR-bestand (Web application Archive), een containerformaat dat alle benodigde code- en configuratiebestanden bevat, en dat bestand te kopiëren naar de webapps-folder van de Tomcat-server. Tomcat zal er dan voor zorgen dat de webapplicatie op de correcte wijze

A.2. FTP-SERVER

75

uitgerold wordt en aldus beschikbaar wordt via het internet.

A.2

FTP-server

Aangezien de bestanden uiteindelijk naar het systeem worden ge¨ upload via FTP, is er een FTP-server nodig. Er wordt gebruik gemaakt van de ProFTPD-server [46]. De ProFTPDserver is een open source FTP-server, die ondanks zijn beperkte omvang toch in grote mate configureerbaar is. De configuratie gebeurt aan de hand van één enkel configuratiebestand, waarin instellingen kunnen worden opgenomen aangaande de gebruikte poorten, de locaties op de schijf, de permissies voor verschillende groepen van gebruikers...

A.3 A.3.1

Gebruikersinterface Webpagina’s

JSP-pagina’s en Servlets genereren, al dan niet dynamische, HTML-output. Om deze output grafisch wat aantrekkelijker en interactiever te maken, heb ik besloten om gebruik te maken van de jQuery JavaScript-bibliotheek. In hoofdstuk 4 werd hier dieper op ingegaan. De reden waarom er gekozen werd voor jQuery is dat men hiermee met vrij weinig moeite toch erg aantrekkelijke gebruikersinterfaces kan maken. Er werden ook enkele componenten uit de jQuery UI-bibliotheek gebruikt om de interactie met het systeem eenvoudiger en overzichtelijker te maken. In hoofdstuk 8 zijn enkele voorbeelden van dergelijke componenten te vinden.

A.3.2

Videospeler

Aangezien het doel van de applicatie is om mediabestanden te beheren, is het erg belangrijk dat deze applicatie in staat is deze bestanden weer te geven aan de gebruikers. Voor het afspelen van de lage resolutie versies van de videofragmenten werd een videospeler ontwikkeld met behulp van Flex (zie 4.2.2). Er werd voor Flex gekozen omdat dit tegenwoordig de meest gebruikte technologie is voor het afspelen van video’s op het internet. De Flash Player die nodig is voor het afspelen van video’s is dan ook aanwezig op de computer van de meeste gebruikers, waardoor er slechts zelden problemen zullen zijn bij het afspelen van de video’s. Bovendien is het ook mogelijk om door middel van JavaScript te communiceren met de Flexapplicatie, wat extra interactiviteit mogelijk maakt. Ik heb hiervan gebruik gemaakt door ervoor te zorgen dat het klikken op een keyframe ervoor zorgt dat er naar de overeenkomende positie in de video wordt gesprongen. De Flex-videospeler werd ontwikkeld met behulp van Adobe Flex Builder.

A.4. DATABANK

A.4

76

Databank

Wanneer men een webapplicatie ontwikkelt van een zekere omvang, moet men een middel hebben waarmee men bepaalde gegevens persistent kan bijhouden: gegevens over gebruikers, over items die toegevoegd zijn aan het systeem... Het is immers niet wenselijk dat al deze gegevens verloren gaan wanneer een gebruiker zijn browser afsluit. Het middel bij uitstek om gegevens op te slaan voor later gebruik, is een databank. Er zijn tegenwoordig heel wat databankbeheerssystemen beschikbaar, al dan niet tegen betaling. Ik koos voor MySQL [47]. MySQL is tegenwoordig ’s werelds meest populaire open source databankbeheersysteem [48]. De installatie en configuratie van MySQL is vrij eenvoudig en als gevolg van de populariteit is er enorm veel informatie te vinden over het werken met MySQL. Ook de functionaliteit die MySQL aanbiedt is voldoende. Het is mogelijk om zelf procedures te schrijven en die op te slaan in het databankbeheersysteem. Het is ook mogelijk om deze procedures automatisch te laten uitvoeren bij bepaalde events in de databank. Bovendien biedt MySQL sinds versie 5.1.5 twee functies aan die het werken met XML-data een stuk eenvoudiger maken. Hiervan wordt handig gebruik gemaakt bij de opslag van de metadata die bij de media items hoort (zie Hoofdstuk 7). De keuze voor MySQL werd dus bepaald door deze aanwezige functionaliteiten en de eenvoud waarmee MySQL te gebruiken is.

A.5

Media operaties

Bij een mediabeheersysteem is het vanzelfsprekend dat er bepaalde operaties kunnen worden uitgevoerd op de mediabestanden. Voorbeelden hiervan zijn het genereren van keyframes, het aanmaken van gecomprimeerde versies die kunnen bekeken worden in de browser en het transcoderen van een mediabestand naar een ander formaat. Er zijn verschillende gratis tools voorhanden die dit soort (en nog vele andere) operaties aanbieden. De meest gebruikte zijn FFmpeg [29] en MEncoder [49]. Beide tools zijn open source. FFmpeg is een commandolijn programma waarmee men onder andere audio en video kan openemen of converteren. MEncoder is eveneens een commandolijn programma, dat min of meer dezelfde functionaliteit aanbiedt als FFmpeg. Bovendien maakt MEncoder gebruik van FFmpeg. Ervaring binnen de vakgroep heeft geleerd dat MEncoder niet altijd even accuraat is als de standalone-versie van FFmpeg: bij bepaalde omzettingen (van HD naar SD) bleek dat een aantal frames te veel of te weinig werden omgezet. Dit gedrag is niet wenselijk (wanneer men bijvoorbeeld nauwkeurig wil monteren) en daarom heb ik er voor gekozen om toch rechtstreeks met FFmpeg te werken. Er is bij de implementatie wel voor gezorgd dat andere tools met een minimum aan moeite kunnen worden ingepast in het systeem. Zo blijft men niet gebonden aan één enkele tool, in dit geval FFmpeg.

A.5. MEDIA OPERATIES

77

Figuur A.1: Gebruikte technologiën: ProFTPD, Flex, jQuery, FFmpeg, Tomcat en MySQL

78

Bijlage B EBU Core specificatie De EBU Core Metadata Set beschrijft een media item aan de hand van een een aantal basiselementen. In deze bijlage wordt een kort overzicht gegeven van deze basiselementen. De meeste van deze elementen zijn optioneel, enkel de titel en een identificatie referentie moeten voorkomen in alle beschrijvingen. Meer informatie hierover is te vinden in de EBU Core specificatie [34].

B.1

Title

Dit is de naam die men geeft aan een item.

B.2

Creator

De Creator is de entiteit (persoon, groep van personen, organisatie) die verantwoordelijk is voor het aanmaken van de inhoud van het item.

B.3

Subject

Het onderwerp dat de inhoud van het item voorstelt. Meestal gebruikt men hier termen uit een beperkte thesaurus, of formele codes.

B.4

Description

Via de Description kan men een tekstuele omschrijving of samenvatting van het item geven.

B.5. PUBLISHER

B.5

79

Publisher

Een Publisher is een entiteit die verantwoordelijk is voor de verspreiding of het beschikbaar maken van het item.

B.6

Contributor

Een Contributor is een entiteit die een substantiële creatieve bijdrage heeft geleverd tot de inhoud van het item.

B.7

Date

Dit is een datum geassocieerd met het item. Men kan bijvoorbeeld de datum aangeven waarop het item is aangemaakt, of beschikbaar gemaakt voor het publiek.

B.8

Type

Type beschrijft het genre of de aard van de inhoud van het item.

B.9

Format

Het Format-element wordt gebruikt om een fysieke vorm van het item te beschrijven. Voorbeelden zijn videofragmenten op tape, of in een bestand op de schijf. Binnen het Formatelement kan allerlei informatie opgenomen worden over dat fragment, zoals de codering, de afmetingen, de bestandsgrootte...

B.10

Identifier

Dit is een unieke referentie waarmee men het item eenduidig kan identificeren binnen een bepaalde context.

B.11

Source

Dit is een referentie naar het item waarvan het huidige item, gedeeltelijk of volledig, is afgeleid.

B.12

Language

Een taal die wordt gebruikt in de inhoud van het item.

B.13. RELATION

B.13

80

Relation

Een Relation duidt een inhoudelijke relatie aan met een ander item.

B.14

Coverage

Aan de hand van het Coverage-element kan men de tijds- en plaatsaspecten van het item beschrijven. Hier kan men bijvoorbeeld opgeven wanneer het item werd gecreëerd of op welke locatie de opnames plaatsvonden.

B.15

Rights

Dit veld wordt gebruikt om de informatie die te maken heeft met allerlei rechten die op het item rusten te identificeren.

B.16

Version

De versie van het item.

B.17

Publication History

Dit element bevat informatie over verschillende publicaties van het item.

B.18

Metada provider

Dit is de entiteit die instaat voor het voorzien van de metadata.

81

Bijlage C Code Bij dit boek werd een cd gevoegd die alle ontwikkelde code bevat. In deze bijlage is een overzicht te vinden van de inhoud van die cd. Voorts wordt er ook beschreven op welke manier men de webapplicatie kan installeren.

C.1 C.1.1

Inhoud cd WSDLConvert

Deze map bevat de broncode en het Visual Studio-project van de tool die beschreven werd in 2.4.2. Een uitvoerbaar bestand is te vinden in de map /WSDLConvert/bin/Release.

C.1.2

CoreMAM.war

Dit is een webarchief dat alle broncode van de webapplicatie bevat. Dit archief kan ook gedeployed worden op een Java-webserver

Importeren in Eclipse Het WAR-bestand kan ge¨ımporteerd worden als een Eclipse-project op de volgende wijze: 1. Open Eclipse 2. File > Import... 3. Kies in de categorie Web voor de optie WAR File en klik op next 4. Selecteer CoreMAM.war en klik op finish

C.2. INSTALLATIE

82

Importeren in Netbeans Om het WAR-bestand te importeren als een Netbeans-project moeten volgende stappen uitgevoerd worden: 1. Pak het WAR-archief uit (bijvoorbeeld met WinRAR) 2. Open Netbeans 3. File > New Project... 4. In de categorie Java Web, kies de optie Web application with Existing Sources 5. Selecteer de map waarin CoreMAM.war is uitgepakt en klik next 6. Stel de juiste parameters in en klik next 7. Klik finish

C.1.3

UploadApplet.jar

Dit archief bevat de broncode van de Applet die gebruikt wordt om de bestanden te uploaden. Het kan ge¨ımporteerd worden in Netbeans of Eclipse op een gelijkaardige manier als de webapplicatie.

C.1.4

CoreMAMDatabaseStructure.sql

Dit is het bestand dat de structuur van de gebruikte databank bevat. Het kan worden gebruikt om een databank te configureren om te worden gebruikt door de webapplicatie.

C.1.5

LowResPlayer.zip

Dit archief bevat de broncode van de ontwikkelde videospeler. Dit archief kan eenvoudig ge¨ımporteerd worden in de Flex Builder via File > Import > Flex Project.

C.2 C.2.1

Installatie Precondities

Opdat de applicatie zonder problemen zou kunnen draaien, moeten er enkele zaken aanwezig zijn op het systeem.

C.2. INSTALLATIE

83

Java-webserver Vooreerst is er een webserver nodig die in staat is Java-webapplicaties te draaien. Ik heb gebruik gemaakt van Apache Tomcat 6.0.18, te downloaden op http://tomcat.apache. org/download-60.cgi.

MySQL-databank De webapplicatie maakt gebruik van een MySQL-databank. Er moet dus een dergelijke databank aanwezig zijn op het systeem. Versie 5.1 kan gedownload worden via http://dev. mysql.com/downloads/mysql/5.1.html#downloads. Om de nodige tabellen uit te maken, kan het bestand CoreMAMDatabaseStructure.sql gebruikt worden als volgt: mysql -u <username> -p<password> mam < CoreMAMDatabaseStructure.sql

FTP-server Om bestanden te kunnen uploaden naar het mediabeheersysteem, is er een FTP-server nodig. Binnen de root-directory van die server moet een map uploads aangemaakt worden waarin de mediabestanden zullen worden upgeload. Voor deze thesis werd gebruikt gemaakt van de PROFTPD-server, te downloaden op http://www.proftpd.org/download.html.

FFmpeg FFmpeg wordt onder andere gebruikt om keyframes en een lageresolutieversie te genereren. Er is geen officiële uitvoerbare versie beschikbaar van FFmpeg, maar de broncode kan gedownload worden via http://www.ffmpeg.org/download.html. Daar is ook te vinden op welke manier deze broncode kan gecompileerd worden tot een werkende versie.

C.2.2

Installeren op Tomcat-server

Om de CoreMAM-applicatie te installeren op een Tomcat-server, volstaat het om CoreMAM.war te kopiëren in de webapps-folder van de Tomcat-server. Tomcat zal er dan automatisch voor zorgen dat de applicatie uitgerold wordt, en kan gebruikt worden. Hoogstwaarschijnlijk zal het bestand app.properties in de map WEB-INF nog moeten aangepast worden, zodat het de juiste configuratieparameters in verband met onder andere de locatie van de server bevat. Ook het bestand context.xml in de META-INF-folder moet mogelijks nog worden aangepast, zodat de connectie met de databank goed kan verlopen.

BIBLIOGRAFIE

84

Bibliografie [1] OpenCube Technologie voor ingest bij VRT. http://www.opencubetech.com/userdoc/ communique_de_presse/vrt_press_release_april_07.pdf. [2] Karel Braeckman and Robbie De Sutter and Maarten Verwaest. Building custom video search upon an existing MAM system. The Fifth IASTED European Conference on Internet and Multimedia Systems and Applications, July 2009. Accepted for publication. [3] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. Technical report, W3C, March 2001. http://www.w3.org/TR/ 2001/NOTE-wsdl-20010315. [4] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H.F. Nielsen, S. Thatte, and D. Winer. Simple Object Access Protocol (SOAP) 1.1. Technical report, W3C, May 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. [5] Common Object Request Broker Architecture. http://www.omg.org/gettingstarted/ corbafaq.htm. [6] Apache Axis. http://ws.apache.org/axis/, April 2006. Version 1.4. [7] WSDL Tool BUG. http://support.microsoft.com/kb/820122, May 2007. Revision 3.4. [8] Jeremy Allaire. Macromedia Flash MX - A next-generation rich client. White Paper, Macromedia, March 2002. Available online (14 pages). [9] Florian Moritz.

Rich internet applications (ria): A convergence of user interface

paradigms of web and desktop. Master’s thesis, University of Applied Science Kaiserslautern, 2008. [10] Wikipedia, the free encyclopedia. http://en.wikipedia.org/. [11] Google Web Toolkit. http://code.google.com/intl/nl/webtoolkit/. [12] J. Resig, B. Aaron, A. Flesler, and J. Zaefferer. jQuery. http://jquery.com/, February 2009. Version 1.3.2.

BIBLIOGRAFIE

85

[13] jQuery UI. http://jqueryui.com/, May 2009. Version 1.7.1. [14] ASP.NET AJAX. http://www.asp.net/ajax/. [15] Adobe Flex. http://www.adobe.com/products/flex/. Version 3. [16] Adobe Flash Player Version Penetration. http://www.adobe.com/products/player_ census/flashplayer/version_penetration.html. [17] Sorenson Spark Video Codec. http://www.sorensonmedia.com/. [18] Macromedia and sorenson media bring video to macromedia flash content and applications. http://www.adobe.com/macromedia/proom/pr/2002/flash_mx_video.html, March 2002. [19] Flash player will support h.264. http://blogs.adobe.com/rgalvan/2007/08/flash_ player_will_support_h264.html, August 2007. [20] BlazeDS AMF Server.

http://opensource.adobe.com/wiki/display/blazeds/

BlazeDS. [21] Adobe Integrated Runtime (AIR). http://www.adobe.com/products/air/. [22] Microsoft Silverlight. http://silverlight.net/. [23] Mono Moonlight: Open Source Alternative for Silverlight. http://mono-project.com/ Moonlight. [24] Java Applets. http://java.sun.com/applets/. [25] JavaFX. http://javafx.com/. [26] OpenLaszlo. http://www.openlaszlo.org/front_page. [27] Curl. http://www.curl.com/. [28] Jerry

Houtman.

boys.

Microsoft

promoot

Silverlight

met

Play-

http://www.spotlighteffect.nl/media/internet/

microsoft-promoot-silverlight-met-playboys/, March 2009. [29] F. Bellard. FFmpeg. http://ffmpeg.org/, 2003. [30] Apache Commons FileUpload. http://commons.apache.org/fileupload/, January 2008. Version 1.2.1. [31] Apache Commons. http://commons.apache.org/, March 2009. [32] Browser Upload Limit. http://www.motobit.com/help/scptutl/pa98.htm.

BIBLIOGRAFIE

86

[33] Apache Commons Net. http://commons.apache.org/net/, October 2008. Version 2.0. [34] EBU Core Metadata Set, technical report 3293-2008. http://tech.ebu.ch/lang/en/ MetadataEbuCore, December 2008. Version 1.0. [35] Dublin Core Metadata Initiative. http://dublincore.org/, January 2008. Version 1.1. [36] ISO/IEC JTC1/SC29/WG11 MPEG-21 Overview v.5. http://www.chiariglione. org/mpeg/standards/mpeg-21/mpeg-21.htm, October 2002. [37] EBU P/META Semantic Metadata Schema, technical report 3295. http://tech.ebu. ch/docs/tech3295v2.pdf, July 2007. Version 2.0. [38] NewsML-G2. http://www.newsml.org, March 2009. Version 2.2. [39] SMPTE Metadata Dictionary RP210-11-2008.

http://www.smpte-ra.org/mdd/,

November 2008. [40] Apache Lucene. http://lucene.apache.org/java/docs/. [41] Christopher D. Manning and Prabhakar Raghavan and Hinrich Sch¨ utze. Introduction to Information Retrieval. Cambridge University Press, 2009. Online edition. [42] Java API for XML Processing. https://jaxp.dev.java.net/. [43] XMLBeans. http://xmlbeans.apache.org/, July 2008. Version 2.4.0. [44] Apache Tomcat. http://tomcat.apache.org/, July 2008. Version 6.0.18. [45] Netbeans IDE. http://www.netbeans.org/. Version 6.5. [46] ProFTPD FTP Server. http://www.proftpd.org/, October 2007. Version 1.3.1. [47] MySQL. http://www.mysql.com/, November 2008. Version 5.1.30. [48] MySQL Market Share. http://www.mysql.com/why-mysql/marketshare/. Overview of various studies. [49] MEncoder. http://www.mplayerhq.hu.

Ontwikkeling van een online mediabeheersysteem

Recommend Documents