Analyse en ontwerp van een t-commerce MHP applicatie voor interactieve digitale televisie

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep: Wireless & Cable Directeur: Prof. Dr. Ir. L. Martens

Analyse en ontwerp van een t-commerce MHP applicatie voor interactieve digitale televisie door Pieter DECONINCK

Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006

Voorwoord Alle personen, die een bijdrage geleverd hebben tot het verwezenlijken van deze verhandeling, wil ik graag met name bedanken. In de eerste plaats mijn promotor, Prof. Dr. Ir. Luc Martens, voor het beschikbaar stellen van dit onderwerp en voor zijn nuttige raadgevingen tijdens de tussentijdse presentatie. Daarnaast wil ik mijn begeleiders Ir. Tom Deryckere en Lic. Michiel Ide bedanken, die mij altijd met raad en daad bijstonden. Tom wekte ook mijn interesse voor dit onderwerp op. Ik wens ook mijn collega-thesisstudenten te bedanken voor het delen van hun kennis via het platform dat ter beschikking werd gesteld door onze begeleiders. Hierbij gaat extra dank naar Toon De Pessemier, die mij verder kon helpen bij problemen over persistente geheugenopslag, Joost Cammaert, wiens code ik kon gebruiken voor de integratie van de elektronische identiteitskaart in mijn applicatie, en Kevin Hoekman, waarbij ik altijd terecht kon met vragen. In het algemeen wil ik ook mijn omgeving bedanken, die mij tijdens de soms moeilijke momenten een hart onder de riem stak. Daarbij een speciaal woordje van dank aan m’n klasgenoten en kotgenoten, waarmee ik een schitterende tijd beleefd heb in Gent. Vervolgens nog een speciaal woord van dank aan mijn ouders, die mij de kans en de mogelijkheden gaven deze studies te volgen. Dank ook voor hun morele steun tijdens het tot stand komen van deze verhandeling. Ik wens mijn mama daarbij extra te bedanken voor het herlezen en verbeteren van mijn thesisbundel. Ook dank aan mijn broers Wouter en Jochen, die me bij problemen altijd wilden helpen.

Pieter Deconinck, juli 2006

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

Pieter Deconinck, juli 2006

Analyse en ontwerp van een t-commerce MHP applicatie voor interactieve digitale televisie door Pieter DECONINCK Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleiders: Ir. T. DERYCKERE, Lic. M. IDE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep: Wireless & Cable Directeur: Prof. Dr. Ir. L. MARTENS

Samenvatting Door het steeds toenemend aantal platformen (desktop computers, mobiele telefoons, PDA’s,. . . ) stijgt de vraag naar applicaties, die bereikbaar zijn vanaf verschillende platformen. Bij dergelijke platform-onafhankelijke applicaties kunnen de voordelen van elk platform benut worden en kan anytime, anywhere and from any device toegang verkregen worden tot een dienst, zoals tcommerce bijvoorbeeld. In het eerste deel van dit eindwerk wordt hierop dieper ingegaan. Na het vergelijken van de typische karakteristieken van de belangrijkste platformen worden richtlijnen besproken voor het ontwerp van dergelijke applicaties. We zullen merken dat grote verschillen bestaan tussen de diverse platformen. De Java 2 Micro Edition, die uitvoerig behandeld wordt, speelt hierop in door het definiëren van configuraties en profielen. In een tweede deel van het eindwerk concentreren we ons dan op t-commerce: de verkoop van producten en diensten via iTV. Na het opsommen van de voor- en nadelen van t-commerce ten opzichte van het traditionele e-commerce, worden twee bestaande t-commerce applicaties besproken. Ook wordt een overzicht gegeven van de vele toepassingsgebieden van t-commerce. Belangrijke onderwerpen bij t-commerce zijn profielbeheer en beveiliging. Deze worden ook uitvoerig behandeld. In een derde deel wordt de verworven theoretische kennis over platform-onafhankelijke applicaties en t-commerce uiteindelijk omgezet in de praktijk. De reeds bestaande Java Smart Ticket Demo, die de verkoop van filmtickets toelaat via handheld toestellen, wordt uitgebreid naar het digitale televisie platform. Hierbij wordt de functionaliteit uitgebreid door toevoeging van onder andere authenticatie op basis van de elektronische identiteitskaart en het afspelen van filmtrailers. Problemen of opmerkingen bij de toepassing van de eerder besproken richtlijnen komen hier aan bod.

Trefwoorden T-commerce, Multimedia Home Platform (MHP), interactieve digitale televisie (iDTV), platformonafhankelijke applicaties, Xlets, MIDlets, J2ME, Java Smart Ticket Demo.

Analysis and development of a t-commerce MHP application for interactive digital television Pieter Deconinck Supervisor(s): Luc Martens, Tom Deryckere, Michiel Ide Abstract— One of the most promising applications in the world of the interactive television are t-commerce applications. T-commerce allows viewers to purchase goods and services through their TV, in other words it’s e-commerce occurring over the TV. In this paper we will take a closer look at crossplatform applications. We will see that it’s important for current commerce application to be cross-platform. Afterwards we concentrate on tcommerce applications and their use. Finally we describe how we adapted Sun’s Java Smart Ticket Demo for handhelds into a cross-platform application that is also available for digital television. Keywords— T-commerce, Multimedia Home Platform (MHP), interactive digital television (iDTV), cross-platform applications, Xlets, MIDlets, J2ME, Java Smart Ticket Demo

these clients access to the functionalities that are provided for these kind of devices [1]. (secure) HTTP Xlet

Java/J2EE Application Server Web tier Web Container

EJB tier EJB Container

EJB

Java Connectors

Servlet

EJB

Java Web Services

MIDlet

EJB EJB

I. I NTRODUCTION HESE days the number of available devices is increasing a lot. In the past, services were only available for computer devices, but nowadays there is a large demand for services available for other devices like handhelds, PDAs, digital televisions,. . . So, cross-platform applications are needed to make it possible to access a service anytime, anywhere and from any device. Cross-platform applications are discussed in section II. A good example of applications which should be cross-platform are commerce applications. By being cross-platform these applications can be adapted in an easy and fast way when new devices appear on the market. An example of such a new device is digital television and we call this type of commerce t-commerce or television-commerce. In section III we take a closer look at t-commerce and we compare it with the existing e-commerce. In section IV we will show how we adapted Sun’s Java Smart Ticket Demo for handhelds to an application that supports digital television. We show which functionalities were added or changed. We will see which guidelines were followed to create a cross-platform t-commerce application. II. C ROSS - PLATFORM APPLICATIONS By creating cross-platform applications a service can use the benefits from each platform. An advantage of mobile devices is that people use it as their personal companion (which makes this device good for anytime and anywhere services), meanwhile digital television is used in a family environment (which makes this a strong tool for family services). In figure 1 we see the layered J2EE architecture that supports different kind of clients (Xlets for digital television, MIDlets for mobile phones and Web browser clients). As we can see, a big part of the server side doesn’t have to be adapted when supporting a new client. We only need to add a new Java servlet in the Web tier that gives P. Deconinck is with the INTEC Broadband Communication Networks (IBCN) Department, Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

Servlet

JMS JavaMail

EJB

Browser

JDBC

Servlet

JSP

T

EIS tier

JNDI CORBA

Fig. 1. The layered J2EE architecture that supports different kind of clients

When developing cross-platform applications the developer should make considerations about the client. First of all this should be done for the network characteristics. The developer should consider which connection is used to connect to the server: a smallband connection, a broadband connection, an interrupted connection,. . . Secondly security considerations should be made. Clients that connect through the enterprise intranet could be less secured than clients that connect through the Internet. The developer should also decide which kind of authentication to use. Thirdly platform considerations should be made. For example for a car ticket service, it wouldn’t be a good idea to choose the digital television platform. The developer should also consider to use a browser client or a Java client. We will now make these considerations for a t-commerce application. The network connection depends on the type of connection that the user has (telephone modem or cable). A solution for this variety in clients is to provide the application in two versions: a smallband version that includes synchronisation and caching mechanisms and that uses the binary format to transport data, and a broadband version where figures can have a higher quality and content can be transported in the XML format. Related to the security considerations, the HTTP protocol should be used, because only in this way all packets will get through the firewalls. For authentication the developer can make use of the electronical identity card. Different platform decisions (browser clients or Java clients) could be made, depending of the application type. Push oriented services (like magazines) prefer a browser client (this is a client with a DVB-HTML browser), while applications with a complex user interface and advanced interaction should choose for Java clients.

III. T- COMMERCE If we compare t-commerce with the traditional e-commerce, we discover some advantages and disadvantages. A few advantages are: iTV applications are more usable than some complex e-commerce sites, you’re shopping in a relaxing environment (in you living room for example), the amount of users is larger, users are familiar with television and will put more trust in tcommerce applications,. . . A few disadvantages are: the screen resolution is lower, less information can be displayed, low hardware capacities, reduced input possibilities, the availability of a t-commerce application depends on the provider,. . . Because of the large amount of disadvantages we can conclude that t-commerce won’t repress e-commerce. During evolution of the digital television, the usage of t-commerce shall be increasing, because less disadvantages will be found and users will get used to interactive television. For some purposes tcommerce is more effective than e-commerce. Specially for advertisement offers, iTV has more possibilities: users can ask for more information during a commercial, tickers with sponsors can be provided when watching a sports competition, publicity integrated in some entertainment applications,. . . Other examples of t-commerce applications are t-banking, payTV, gambling, lottery,. . . Nowadays browser clients are far more popular than Java clients for the computer platform. We believe that this phenomenon also will take place for digital television in the future. The only problem that we encounter is that future set-top boxes are not forced to support DVB-HTML. That’s why some commercial companies implemented already their own DVB-HTML browser for their interactive applications [2][3]. T-commerce adds some possibilities for profile management. Set-top boxes have a unique identification number that can be used by the server to save a profile of the family that uses the set-top box. In the near future set-top boxes will also contain information (like a postcode) that could be acquired by the application. This kind of information could be used to personalize the application. To maintain the confidence in digital television, security facilities should be provided. A smart card reader could be used to read the information on a electronic identity card. A doubled security could be created by combining this authentication by electronic identity card with a login/password combination. Obviously secured connections should be used and data should be encrypted. IV. A DAPTATION OF THE JAVA S MART T ICKET D EMO FOR DIGITAL TELEVISION

All previous matters were put into reality by adapting the Java Smart Ticket Demo for handhelds to digital television. The Java Smart Ticket Demo is a service for buying filmtickets for a specific movie in a cinema [4]. The transformation of the original MIDlet to a new Xlet was not that easy. While MIDlets consist of standard components (such as List) that implement their own interactivity and user interface, Xlet user interfaces have to be implemented completely manually, inclusive the interactivity. The resulting application is shown in figure 2. Because of simplicity, we made the decision not to adapt the

Fig. 2. Screenshot of the Java Smart Ticket Demo for digital television

code at the server side. In this way, existing Java Smart Ticket servers could easily support digital television client without being reinstalled. A disadvantage of this choice is that the new application for digital television maximally can support the same functionalities as the original Java Smart Ticket Demo, because the same servlet was used. We can conclude that, in a real application, it should be necesary to support another servlet specific for digital television. In this way, all strengths of each platform could be utilized by offering functionalities through his own servlet. In spite of the restriction that we didn’t adapt the server side, we succeeded in creating some new functionalities in the adapted application. These are for example authentication of users by their electronic identity card and providing trailers of the films of the Java Smart Ticket Demo. This adapted Java Smart Ticket Demo supports some basic mechanisms for all t-commerce applications. These mechanisms could easily be reused to create another t-commerce application like a t-shopping application, a gambling service,. . . The implemented application is a basis for future work related to tcommerce. The application can also be seen as an example of a cross-platform application, that is implemented according to the guidelines mentioned in [1]. R EFERENCES [1] Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition. I. Singh, B. Stearns, M. Johnson, Enterprise Team. Copyright 2002. [2] Pontegra t-commerce. http://www.nionex.de/home/loesungen/itv/ [3] Ortikon Interactive. http://www.ortikon.com [4] http://developers.sun.com/techtopics/mobility/midp/articles/smartticket1 2/

VERKLARENDE WOORDENLIJST

Verklarende woordenlijst Acroniemen ADSL

Asymmetric Digital Subscriber Line.

AMS

Application Management Software.

API

Application Programming Interface.

ARPU

Average Revenue Per User.

AWT

Abstract Windowing Toolkit.

CA

Certificate Authority.

CDC

Connected Device Configuration.

CLDC

Connected Limited Device Configuration.

CHTML

Compact HTML.

CMS

Content Management System.

CNP

Card Not Present.

CPU

Control Processing Unit.

CVM

Compact Virtual Machine.

CSS

Cascading Style Sheets.

DASE

DTV Applications Software Environment.

DHTML

Dynamic HTML.

DOM

Document Object Model.

DTD

Document Type Definition.

DTV

Digital Television.

DVB

Digital Video Broadcasting.

DVB-HTML

Digital Video Broadcasting HTML.

DVD

Digital Versatile Disk.

DVR

Digital Video Recorders.

EPG

Electronic Programming Guide.

i


ETSI

European Telecommunications Standard Institute.

FP

Foundation Profile.

EJB

Entity Java Bean.

GUI

Graphical User Interface.

HAVi

Home Audio-Video interoperability.

HTML

Hypertext Markup Language.

HTTP

Hypertext Transfer Protocol.

HTTV

High Tech Television.

IIOP

Internet Inter-Orb Protocol.

IMP

Information Module Profile.

IP

Internet Protocol.

iTV

interactive Television.

iDTV

interactive Digital Television.

KVM

Kilobyte Virtual Machine.

JAR

Java Archive.

JAXP

Java API for XML Processing.

JCP

Java Community Process.

JDBC

Java Database Connectivity.

JNLP

Java Native Launching Protocol.

JRE

Java Runtime Environment.

JSP

Java Server Pages.

JSSE

Java Secure Sockets Extension.

JVM

Java Virtual Machine.

J2EE

Java 2 Enterprise Edition.

J2ME

Java 2 Micro Edition.

J2SE

Java 2 Standard Edition.

MHP

Multimedia Home Platform.

MIDP

Mobile Information Device Profile.

MIME

Multipurpose Internet Mail Extensions.

m-commerce mobile commerce. NVOD

Near Video On Demand.

OCAP

OpenCable Application Profile.

ii


OS

Operating System.

PBP

Personal Basis Profile.

PC

Personal Computer.

PDA

Personal Digital Assistant.

PDAP

Personal Digital Assistant Profile.

PPV

Pay Per View.

QoS

Quality of Service.

RAM

Random Access Memory.

RMI

Remote Method Invocation.

RMS

Record Management Store.

ROI

Return On Investment.

RPC

Remote Procedure Call.

SAX

Simple API for XML.

SET

Secure Electronic Transfer.

SMIL

Synchronized Multimedia Integration Language.

SMS

Short Message System.

SOAP

Simple Access Object Protocol.

SVG

Scalable Vector Graphics.

SSL

Secure Socket Layer.

STB

Set-Top Box.

TLS

Transport Layer Security.

t-commerce television commerce. UI

User Interface.

URI

Uniform Resource Identifier.

URL

Uniform Resource Locator.

VM

Virtual Machine.

VOD

Video On Demand.

VoiceML

Voice Markup Language.

WML

Wireless Markup Language.

WWW

World Wide Web.

W3C

World Wide Web Consortium.

XHTML

Extensible HTML.

XSL FO

Extensible Stylesheet Language Formatting Objects.

iii

INHOUDSOPGAVE

iv

Inhoudsopgave Verklarende woordenlijst

i

1 Inleiding

1

1.1

Platform-onafhankelijke applicaties . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

T-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2 Platform-onafhankelijke applicaties

3

2.1

Het belang van platform-onafhankelijke applicaties . . . . . . . . . . . . . . . . .

3

2.2

Voorstelling van de verschillende platformen . . . . . . . . . . . . . . . . . . . . .

6

2.2.1

Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.2

Mobiele telefoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.3

Digitale televisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

De client zijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3.1

Client overwegingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3.2

Algemene richtlijnen voor het ontwerp van clients . . . . . . . . . . . . . .

15

2.3.3

Richtlijnen voor browser clients . . . . . . . . . . . . . . . . . . . . . . . .

16

2.3.4

Richtlijnen voor Java clients . . . . . . . . . . . . . . . . . . . . . . . . . .

21

De server zijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.4.1

Java Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

2.4.2

Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.4.3

Transactie Management . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

De communicatie tussen client en server . . . . . . . . . . . . . . . . . . . . . . .

30

2.5.1

Browser clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.5.2

Java clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.3

2.4

2.5

3 Java 2 Micro Edition (J2ME)

36

INHOUDSOPGAVE

3.1

3.2

3.3

v

Configuraties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.1.1

Connected Limited Device Configuration (CLDC) . . . . . . . . . . . . .

38

3.1.2

Connected Device Configuration(CDC) . . . . . . . . . . . . . . . . . . .

39

Profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.2.1

Profielen voor CLDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3.2.2

Profielen voor CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

De verschillende applicatiemodellen binnen J2ME . . . . . . . . . . . . . . . . . .

44

3.3.1

Het traditionele applicatie model . . . . . . . . . . . . . . . . . . . . . . .

44

3.3.2

Het Applet model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

3.3.3

Het MIDlet model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

3.3.4

Het Xlet model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4 T-commerce en zijn toepassingen

56

4.1

De voor- en nadelen van t-commerce ten opzichte van e-commerce . . . . . . . .

56

4.2

Bestaande t-commerce applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.2.1

Pontegra t-commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.2.2

Ortikon interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

4.3.1

Push services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

4.3.2

Entertainment & games . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

4.3.3

T-banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.3.4

T-shopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.3.5

Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

4.3.6

PayTV

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

67

4.3.7

Gambling & lottery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

4.3

5 Profielbeheer en beveiliging 5.1

5.2

69

Profielbeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

5.1.1

Het identificeren van klanten . . . . . . . . . . . . . . . . . . . . . . . . .

70

5.1.2

Personalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

Beveiliging

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

75

5.2.1

Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

5.2.2

Betalingswijzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

INHOUDSOPGAVE

vi

6 De Java Smart Ticket Demo 6.1

6.2

79

De Java Smart Ticket Demo voor handhelds . . . . . . . . . . . . . . . . . . . . .

80

6.1.1

De functionaliteiten van de Java Smart Ticket Demo . . . . . . . . . . . .

82

6.1.2

De architectuur van de Java Smart Ticket Demo . . . . . . . . . . . . . .

85

6.1.3

De Java Smart Ticket Demo in de realiteit

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

87

De Java Smart Ticket Demo voor digitale televisie . . . . . . . . . . . . . . . . .

87

6.2.1

De client zijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

6.2.2

De server zijde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

6.2.3

Het transport tussen de client en server zijde . . . . . . . . . . . . . . . .

94

7 Conclusies

95

A Inhoud van de begeleidende Cd-rom

98

INLEIDING

1

Hoofdstuk 1

Inleiding Door de analoge technologie was het bekijken van televisie de laatste 50 jaar een passieve activiteit. Maar hieraan komt nu een einde. Tegenwoordig verbetert de digitale technologie in sterke mate de traditionele broadcasting: meer kanalen binnen dezelfde bandbreedte, betere beeldkwaliteit, hi-fi geluidsweergave,. . . Maar deze verbeteringen zijn slechts neveneffecten van de revolutie die digitalisering in onze living zal brengen. De komende jaren zal het bekijken van televisie verbeterd worden door vele nieuwe mogelijkheden, en de kijkers zullen niet langer gelimiteerd zijn tot het observeren van content die geselecteerd werd door operatoren. Meer en meer worden dynamische en interactieve diensten ge¨ıntroduceerd in programma’s van digitale broadcasting platformen: bijkomende informatie bij audiovisuele content, elektronische programmagidsen, de selectie van eigenschappen voor configureerbare content (taal, camerapositie of aangepaste reclameboodschappen), Pay-Per-View, spelletjes,. . . Deze interactieve applicaties maken de rol van de kijker actiever, zoals bij Web browsing het geval is. Het broadcasten van een digitale transport stroom laat operatoren toe traditionele audiovisuele content te mixen met binaire data, zodat het mogelijk wordt gemaakt applicaties af te leveren die dan uitgevoerd worden in een digitale televisie of een set-top box. Het doel van deze thesis is de analyse en ontwerp van een t-commerce MHP-applicatie voor interactieve digitale televisie. Voordat we, in deze inleiding, t-commerce zullen toelichten, zullen we eerst een belangrijke vereiste geven voor de meeste hedendaagse handelsapplicaties, namelijk platform-onafhankelijkheid.

1.1

Platform-onafhankelijke applicaties

Door het steeds toenemend aantal platformen (desktop computers, mobiele telefoons, PDA’s,. . . ) stijgt de vraag naar applicaties die bereikbaar zijn vanaf verschillende platformen: platformonafhankelijke applicaties. Door het gebruik van dit soort applicaties stijgt niet alleen de toegankelijkheid van de dienst (meer gebruikers kunnen er immers toegang tot verkrijgen) maar ook de efficiëntie (want de voordelen van elk platform kunnen benut worden). Platform-onafhankelijke applicaties zijn dan ook zeer toepasbaar bij handelsdiensten. Het biedt de klanten de mogelijkheid om anytime, anywhere and from any device toegang te verkrijgen tot de dienst, zodat ze om het even waar en wanneer aankopen kunnen doen. Hoofdstuk 2 bespreekt eerst het belang van dergelijke platform-onafhan-kelijke applicaties. Vervolgens worden de drie belangrijkste platformen (computer, mobiele telefoon en digitale

1.2 T-commerce

2

televisie) vergeleken op verschillende gebieden (hardwarekarakteristieken, netwerkkarakteristieken,. . . ). Daaruit zullen dan conclusies getrokken worden voor het ontwerpen van goede platform-onafhankelijke applicaties. Hierbij wordt een opsplitsing gemaakt tussen de client zijde, de server zijde en de communicatie hiertussen. Na een bespreking van de belangrijkste platformen volgt in hoofdstuk 3 een situering van deze platformen binnen de Java 2 Micro Edition (J2ME). We zullen het gebruik van configuraties en profielen bij J2ME toelichten en zullen in dit kader ook de MHP specificaties situeren. Het zal ons opvallen dat niet alle toestellen dezelfde capaciteiten hebben en daarom gegroepeerd worden in categoriën. Het hoofdstuk wordt afgesloten met een studie van de verschillende applicatiemodellen binnen J2ME: het traditionele applicatie model, het Applet model, het MIDlet model en het Xlet model.

1.2

T-commerce

T-commerce laat kijkers toe producten of diensten aan te kopen via hun televisie, het is met andere woorden e-commerce maar dan via iTV. In hoofdstuk 4 wordt dieper ingegaan op het begrip t-commerce. Ook worden de voor- en nadelen van t-commerce ten opzichte van e-commerce gepresenteerd. Tegenwoordig wordt t-commerce ook reeds in de praktijk gebruikt. Twee bestaande applicaties, Pontegra t-commerce en Ortikon interative, die een DVB-HTML browser implementeren, worden verder in dit hoofdstuk besproken. T-commerce biedt vele toepassingen: gaande van eenvoudige push-services zoals televisie magazines waarvoor betaald moet worden, tot geavanceerde t-shopping applicaties in het genre van e-bay. Deze toepassingen zullen als laatste vermeld worden in hoofstuk 4. Bij t-commerce applicaties zijn twee onderwerpen belangrijk: profielbeheer en beveiliging. In hoofdstuk 5 wordt hier dieper op ingegaan. Verschillende technieken om klanten te identificeren worden beschreven en er wordt voorgesteld hoe een applicatie kan gepersonaliseerd worden. Op vlak van beveiliging wordt aandacht geschonken aan authenticatie. Verschillende authenticatiemechanismen zullen aan bod komen zoals bijvoorbeeld het gebruik van de elektronische identiteitskaart voor t-commerce applicaties. Tot slot worden verschillende mogelijke betalingswijzen voor t-commerce applicaties omschreven. In hoofdstuk 6 worden uiteindelijk alle theoretisch behandelde onderwerpen uit de vorige hoofdstukken toegepast in de realiteit. Er werd geopteerd om een bestaande applicatie voor handhelds uit te breiden naar een platform-onafhankelijke applicatie voor digitale televisie. In dit hoofdstuk zal de keuze gemotiveerd worden voor het gebruik van een reeds bestaande applicatie: de Java Smart Ticket Demo. Deze applicatie maakt het mogelijk filmtickets aan te kopen via een handheld apparaat (zoals een mobiele telefoon, PDA,. . . ). Als kennismaking met de Java Smart Ticket Demo worden de functionaliteiten en de architectuur ervan beschreven. In het tweede deel van hoofstuk 6 wordt dan de aanpassing besproken van de Java Smart Ticket Demo tot een applicatie voor digitale televisie. Na het beschrijven van de nieuwe en aangepaste functionaliteiten wordt aangetoond hoe de implementatierichtlijnen voor platformonafhankelijke applicaties (van uit hoofdstuk 2) in de realiteit werden toegepast. De aangepaste applicatie heeft als extra functionaliteit de integratie van de elektronische identiteitskaart voor de authenticatie van de gebruiker en het aanbieden van trailers aan de gebruiker. Ten slotte worden in hoofdstuk 7 de conclusies behandeld. In Bijlage A wordt de inhoud van de bijgeleverde CD-rom vermeld.

PLATFORM-ONAFHANKELIJKE APPLICATIES

3

Hoofdstuk 2

Platform-onafhankelijke applicaties 2.1

Het belang van platform-onafhankelijke applicaties

Hedendaagse software-ontwikkelaars hebben een sterk groeiende keuze uit diverse platformen en toestellen: desktop computers, mobiele telefoons, PDA’s, laptops, game consoles, digitale televisie,. . . Dit aanbod zal de komende jaren nog meer uitbreiden naarmate nieuwe technologieën ge¨ıntroduceerd zullen worden in het marktaanbod. Het is onwaarschijnlijk dat één enkel platform perfect zal zijn voor een specifieke dienst, zoals bijvoorbeeld handel (commerce) via het internet. In de huidige situatie wordt deze dienst voornamelijk aangeboden voor desktop computer of laptops door middel van e-commerce. Dit is echter een medium dat niet voor iedereen toegankelijk is en houdt op die manier deze dienst buiten het bereik van bepaalde mensen. Ook vertoont e-commerce bepaalde zwakheden, waardoor potentiële klanten afgeschrikt worden. Complexiteit van e-commerce sites en het wantrouwen in computers zijn enkele voorbeelden van dergelijke zwakheden. Deze zwakheden kunnen opgevangen worden door de dienst mogelijk te maken op andere toestellen, die gemakkelijker in gebruik zijn en betrouwbaarder worden ervaren, zoals digitale televisie en mobiele telefoons. Mobiele telefoons hebben als sterkte dat ze constant binnen het bereik zijn van de gebruiker, zodat deze op om het even welk moment toegang heeft tot de dienst. Bij deze vorm van handel, ook wel m-commerce genoemd, kan hij bijvoorbeeld gemakkelijk een parkeerplaats reserveren en de corresponderende wegbeschrijving ontvangen terwijl hij in zijn wagen zit (wat uitgewerkt wordt in het Mobile Enterprise Handy Parking Project waarover meer informatie terug te vinden is in [1]). Terwijl de mobiele telefoons individuele toestellen zijn, wordt de digitale televisie ervaren als een familiegebeuren. Zo kan, bij de aankoop van producten voor het hele gezin, interactief multimediamateriaal zoals foto’s en films bekeken worden. Deze vorm van handel wordt t-commerce genoemd, waarop teruggekomen wordt in hoofdstuk 4. Mobiele telefoons en digitale televisie hebben dan weer als nadeel dat ze respectievelijk een klein beeldscherm hebben om informatie weer te geven en dat de beeldresolutie lager is dan bij computers. Vele diensten zullen een beroep doen op de sterktes van een combinatie van toestellen. Als voorbeeld nemen we de ge¨ımplementeerde applicatie uit hoofdstuk 6 (de Java Smart Ticket Demo), waar filmtickets gekocht kunnen worden met de computer, mobiele telefoon én digitale televisie. Zo kunnen gebruikers, die lange wachtrijen willen vermijden, al tickets aankopen, terwijl ze nog op weg zijn naar de cinema. Gebruikers, die daarentegen vooraf de trailer willen

2.1 Het belang van platform-onafhankelijke applicaties

4

bekeken hebben, kunnen hun tickets interactief kopen met hun digitale televisie. Gebruikers, die uitgebreide recensies willen lezen of interviews met de acteurs, maken dan best gebruik van een desktop computer of laptop om toegang te krijgen tot de dienst. Het verspreiden van de functionaliteit over verschillende toestellen kan op deze manier wel problemen scheppen voor de applicatieontwikkelaars, die voor consistentie en coherentie zullen moeten zorgen over de verschillende technologieën. Zo zal de interactie en user interface gelijkaardig moeten zijn voor de ondersteunde platformen, zodat de gebruikers geen problemen hebben met de overschakeling van het ene toestel naar het andere. Er zal ook rekening moeten gehouden worden met het feit dat een gebruiker tegelijk aangemeld kan zijn via verschillende toestellen. Dit soort applicaties worden platform-onafhankelijke applicaties genoemd of ook wel crossplatform applicaties. Voordat we implementatie- en ontwerprichtlijnen kunnen geven voor dit soort applicaties moeten we eerst de karakteristieken van de belangrijkste platformen onderzoeken. Dit wordt gedaan in sectie 2.2 voor de drie meest gebruikte platformen: computer, mobiele telefoon en digitale televisie. We laten diverse platformen buiten beschouwing, omdat deze ofwel goed corresponderen met voorgaande platformen of een combinatie ervan, ofwel tot op heden weinig gebruikt werden voor platform-onafhankelijke applicaties. Zo vertoont de PDA (Personal Digital Assistent), die samen met de mobiele telefoons ook tot de handheld groep behoort, karakteristieken van mobiele telefoons én van computers. Er wordt verwacht dat veel meer platformen in de toekomst toegang zullen verkrijgen tot eenzelfde dienst, zoals bijvoorbeeld handel via het Intenet. Zo zal men misschien over tientallen jaren de ingrediënten van een recept, dat men gevonden heeft met de digitale televisie, via het kookfornuis in de keuken kunnen bestellen en afhalen bij de plaatselijke supermarkt. Door de karakteristieken van de platformen te vergelijken zullen we op deze manier ontdekken wat de moeilijkheden zijn bij het ontwikkelen van platform-onafhankelijke applicaties. Deze informatie zullen we gebruiken bij het beschrijven van bepaalde implementatie- en ontwerprichtlijnen. De applicatie zal worden opgesplitst in drie delen: de client-zijde, de server-zijde en het transport tussen beide. De richtlijnen voor deze drie delen worden respectievelijk besproken in de secties 2.3, 2.4 en 2.5. Bij het opstellen van de richtlijnen voor het ontwikkelen van applicaties werden vier aspecten extra beklemtoond. • Beschikbaarheid: Anytime, anywhere, from any device” ” De dienst moet continu (24 uur op 24, 7 dagen op 7) toegankelijk zijn, waarbij de downtijd geminimaliseerd wordt. Op om het even welke plaats zou je toegang moeten kunnen krijgen tot de dienst door eventueel verschillende vormen van communicatie met de applicatie server (bijvoorbeeld: kabel, sateliet, BlueTooth,. . . ). Zoals hierboven uitgelegd zou deze toegang ook vanaf eender welk toestel moeten kunnen gebeuren. Hier speelt ook internationalisatie (i18n) een grote rol. De applicatie is pas echt beschikbaar voor iedereen als verschillende talen worden ondersteund. • Usability Gebruikerservaring zijn bij dit soort applicaties van uiterst belang. Daarom moet veel aandacht besteed worden aan de user interface en de interactie met de gebruiker. De applicatie moet gemakkelijk in gebruik zijn. Er moet rekening gehouden worden met het verschil in niveau tussen de verschillende gebruikers en ze zouden consistentie moeten

2.1 Het belang van platform-onafhankelijke applicaties

5

ervaren bij de verschillende toestellen waarop de dienst toegankelijk is. De applicatie moet dus herkend worden als eenzelfde applicatie op de verschillende toestellen. Dit kan door het creëren van een gelijkaardige user interface, het ondersteunen van gelijkaardige interactie of het weergeven van een zelfde merknaam of -figuur. • Aanpasbaarheid De applicatie moet gemakkelijk aan te passen zijn op allerlei vlakken. Zo zouden de content provider, grafische ontwerper en programmeur onafhankelijk van elkaar hun werk moeten kunnen doen. Heel belangrijk is dat de content aangepast moet kunnen worden zonder de code te moeten veranderen. De applicatie moet ook gemakkelijk uitbreidbaar zijn. • Performantie Uiteraard moet ook de performantie van de applicatie zo goed mogelijk zijn. Bij eventuele slechte performantie (door te klein geheugen, te trage processor,. . . ) zou de gebruiker hiervan zeker niets mogen merken, maar bijvoorbeeld een wacht-boodschap op het scherm moeten krijgen. • Betrouwbaarheid De applicatie moet veilig zijn om het vertrouwen van de gebruiker erin te garanderen. Authenticatie en beveiligde transacties zijn zeker een noodzaak. Hoewel in de huidige situatie weinig gebruik gemaakt wordt van platform-onafhankelijke applicaties zijn er toch enkele voorbeelden terug te vinden. Een platform-onafhankelijke learning applicatie wordt uitgewerkt in [2] waar een applicatie voorgesteld wordt voor het aanleren van een taal door het gebruik van interactieve digitale televisie (iTV) en mobiele telefonie. Een ander voorbeeld is de cross-platform multimedia SMIL player die wordt besproken in [3]. Op deze speler, die op de computer en digitale televisie werkt, wordt later in sectie 2.3 nog teruggekomen. Verschillende comerciële bedrijven investeren ook in platform-onfhankelijke applicaties: AmigaAnywhere [4], PixelPlay Inc. [5], HTTV (High Tech TV) [6],. . . We merken op dat de definitie platform-onafhankelijk ook betrekking kan hebben tot systeemplatformen. De wikipedia [7] leert ons dat een software applicatie of hardware toestel platformonafhankelijk is, als het werkt op verchillende systeemplatformen zoals bijvoorbeeld Linux/Unix, Microsoft Windows en Mac OS X. Webpagina’s worden vaak platform- of browseronafhankelijk genoemd, wanneer ze kunnen gebruikt worden vanaf elke browser, of minstens vanaf elke recente browser. Naast het creëren van geldige code vereist dit vaak ook van de auteur de kennis van de eigenaardigheden van bepaalde browsers (zoals Microsoft Internet Explorer) die niet nauwkeurig omgaan met webstandaarden. Een webpagina, die inhoud aanbiedt die niet door alle browsers kan getoond worden, zoals Macromedia Flash-animaties, kan toch platform-onafhankelijk gemaakt worden, als er voorzieningen getroffen worden voor gebruikers, die de speciale ondersteuning of plugins niet hebben. Men kan bijvoorbeeld afbeeldingen tonen in de plaats van complexere inhouden, of een downloadbare MPEG-versie van geanimeerd materiaal aanbieden. Platform-onafhankelijke toegankelijkheid op het Web vereist het begrijpen van de gebruikers, maar ook van technische standaarden. Wanneer men wil dat een pagina toegankelijk is voor een groot aanbod aan platformen zoals Braille-gebaseerde webbrowsers, kleine toestellen zoals mobiele telefoons en PDA’s, digitale televie,. . .

2.2 Voorstelling van de verschillende platformen

2.2

6

Voorstelling van de verschillende platformen

In deze sectie worden de drie belangrijkste platformen besproken voor de huidige ontwikkeling van interactieve diensten. Deze zijn: het computer-medium (desktop computers, laptops,. . . ), mobiele telefoons en digitale televisie. We merken op dat deze platformen op verschillende vlakken bepaalde karakteristieken vertonen, waarin ze verschillen of overeenkomen. We groeperen deze karakteristieken als volgt. • Fysische karakteristieken: schermgrootte, resolutie, kijkafstand, input apparaten • Hardware karakteristieken: persistente geheugenopslag, RAM geheugen, CPU snelheid, levensduur batterij • Netwerkkarakteristieken: latentie, bandbreedte, onderbroken connectiviteit • Algemene eigenschappen van het platform: hoeveelheid gebruik, hoe het ervaren wordt door de gebruiker • User interface, interactie en navigatie: opbouw user interface (UI), hoeveelheid interactie, gebruik van hyperlinks Om snel een beeld te krijgen van de verschillen en gelijkenissen tussen de verschillende platformen werden bepaalde karakteristieken in tabel-vorm uiteengezet. We merken op dat er in deze tabellen ook PDA’s vermeld worden, maar deze niet verder bestudeerd worden in het vervolg van deze sectie. Tabel 2.1 toont de fysische karakteristieken en tabel 2.2 de hardware karakteristieken. Er dient wel opgemerkt te worden, dat de gebruikte gegevens enorm variabel zijn en dat het hier slechts gaat om voorbeelddata, die de algemene verschillen en gelijkenissen willen aantonen tussen de verschillende platformen. Tabel 2.1: Fysische karakteristieken Platform Digitale televisie Mobiele telefoon PDA Desktop PC

Resolutie (pixels) 720x576 (minimaal) 84x48 tot 120x130 160x160 tot 240x320 640x480 tot 1800x1440

Kijkafstand 2-3 m 30 cm 30 cm 60 cm

Input apparaat remote control key pad keyboard/pen muis/toetsenbord

Schermbreedte 60 cm 3 cm 10 cm 35 cm

Tabel 2.2: Hardware restricties van de verschillende apparaten Platform Digitale televisie Mobiele telefoon PDA Desktop PC

Geheugenopslag (MB) 16 tot 40.000 0,5 32 40.000

RAM geheugen 32-64 0,2 32-64 128-512

CPU snelheid 233-333 MHz 20 MHz 206 MHz 2 GHz

We zullen nu de bovenstaande karakteristieken wat meer in detail behandelen voor de drie belangrijkste plaformen: computer, digitale televisie en mobiele telefoon. We zullen ook telkens de gevolgen hiervan behandelen voor het applicatie-ontwerp. De specifieke implementatie- en ontwerprichtlijnen volgen later in de secties 2.3, 2.4 en 2.5 voor respectievelijk de client, de server en het transport ertussen.


2.2.1

7

Computer

Dit is het meest gekende medium voor het aanbieden van interactieve diensten aan de gebruikers. Het platform bestaat uit een grote diversiteit aan toestellen, gaande van eenvoudige PC’s tot krachtige mainframes. Om deze reden en wegens de grote hoeveelheid informatie die reeds terug te vinden is in de literatuur, gaan wij dit platform eerder snel behandelen. Fysische karakteristieken De beeldschermen van computers hebben een schermgrootte variërend tussen 13 en 28 inches. Het beeld kan nog groter worden weergegeven door het te projecteren op een groter vlak. De resolutie varieert meestal tussen 640×480 en 1800×1440 en de kijkafstand is ongeveer 60 cm. De gebruiker kan via een groot aanbod aan inputapparaten interageren met de computer. De basis inputapparaten zijn de muis en het toetsenbord, maar dit kan uitgebreid worden naar bijvoorbeeld een touch-screen, een digitale tekentafel,. . . Eigenlijk heeft een computer nog vele andere inputapparaten zoals bijvoorbeeld een scanner, cd-rom station of externe harde schijf, die onrechtstreeks ook tot de interactie bijdragen met de gebruiker. Zo is een smartcard lezer ook een inputapparaat, waarmee de gebruiker, na het inpluggen van zijn elektronische identiteitskaart, zich kan identificeren. Hierop komen we terug in hoofdstuk 5. Hardware karakteristieken In vergelijking met andere platforms heeft de computer heel weinig hardware beperkingen. Zowel het persistente geheugen als het RAM geheugen kunnen gemakkelijk uitgebreid worden door bijvoorbeeld een externe harde schijf of een bijkomend RAM geheugen. De snelheden van de huidige processors zijn meestal zodanig groot, dat gebruikers nauwelijks hoeven te wachten op resultaten van zware berekeningen. Indien mogelijk kan er dus geopteerd worden om zware bewerkingen uit te voeren aan de client-zijde in plaats van aan de server-zijde. Men moet er wel rekening mee houden, dat er nog steeds vele mensen verouderde trage computers gebruiken, die in voorgaande situatie in de problemen zouden komen. Desktop computers kunnen 24 uur op 24 actief zijn, laptops daarentegen hebben een beperkte batterij levensduur, die sterk varieert van enkele uren tot meerdere dagen. Belangrijk te vermelden is dat computergebruikers het niet abnormaal vinden dat hun computer (met meestal als besturingssysteem Microsoft Windows) af en toe crasht of vastloopt voor een bepaalde duur, dit in tegenstelling tot gebruikers van digitale televisie of mobiele telefoon die dit niet verwachten van hun toestel. Netwerkkarakteristieken De meeste computers krijgen toegang tot het internet via telefoonmodem, ADSL of breedband kabel. Bij telefoonmodems spreken we van een onderbroken connectiviteit. De gebruikers moeten telkens inbellen om toegang te krijgen tot een dienst op het internet. Omdat dergelijke gebruikers meestal per tijdseenheid gefactureerd worden, trachten zij de connectietijd te minimaliseren. Applicatieontwikkelaars zouden dus rekening moeten houden met het feit dat


8

bepaalde gebruikers zo kort mogelijk verbonden willen zijn en bovendien over een trage verbinding beschikken. Een oplossing is om gebruikers te laten kiezen wanneer ze verbinding willen maken met de server en de applicatie offline beschikbaar te maken. Wanneer de gebruiker dan connecteert met het netwerk zal hij de gegevens kunnen synchroniseren met deze op de server. Bij het online browsen is het voor een computergebruiker normaal dat pagina’s moeten ingeladen worden en dat dit tijd neemt. Hij vindt het dan ook niet erg dat gegevens stuk-voor-stuk worden ingeladen. Bepaalde informatie kan ook gecached worden, zodat ze sneller kan ingeladen worden bij een volgende opvraging. Men dient wel op te passen met het cachen van gevoelige informatie zoals paswoorden. Door deze op te slaan kan elke persoon, die de computer gebruikt, zich aanmelden onder deze gegevens. Algemene eigenschappen van het platform Bij een computer heeft de gebruiker de volle concentratie op de applicatie en wordt hij niet afgeleid door televisiebeelden zoals dat het geval is bij digitale televisie. Dit zal resulteren in gebruikers, die actiever zijn. De personal computer (PC) of laptop wordt ook meestal door slechts één enkele persoon bediend, terwijl televisie-kijken een familiegebeuren is. In tegenstelling tot een mobiele telefoon, kan de computer wel achtereenvolgens door meerdere personen gebruikt worden, waarmee rekening moet gehouden worden bij ontwerp. Bij Web applicaties via computer zal tekst eerder centraal staan in plaats van videobeelden of audio. Omwille van de grote concurrentie bij applicaties voor het computer medium zullen gebruiksvriendelijkheid en usability belangrijke factoren zijn, die de gebruiker zullen overtuigen om de applicatie verder te gebruiken. Enkele nadelen van dit platform zijn, dat niet iedereen over een computer beschikt (terwijl bijna iedereen een mobiele telefoon heeft), dat sommigen een computer als minder betrouwbaar beschouwen, dat het tijd vraagt om ermee te leren werken, en dat men het toestel niet altijd onmiddellijk bij de hand heeft. User interface, interactie en navigatie Bij computers kan de user interface variëren van heel eenvoudig tot uiterst complex. Er zijn weinig richtlijnen voor het ontwikkelen van een user interface voor het computer platform en dit creëert een grotere vrijheid. Er zijn vele vormen van interactie met de gebruiker mogelijk: klikken met de muis, intikken van gegevens, naar het einde van de pagina scrollen,. . . Wat de navigatie betreft zijn er ook weinig beperkingen. Zo is er een uitgebreid aanbod aan hyperlinks, menu’s, aanklikbare links,. . . Desondanks deze grote vrijheid moet erop worden toegezien dat de usability en gebruiksvriendelijkheid gegarandeerd blijven.

2.2.2

Mobiele telefoon

Fysische karakteristieken Een mobiele telefoon heeft een schermgrootte van ongeveer 6 inches en is dus gelimiteerd wat betreft de tekstweergave. Sans serif lettertypes zoals Arial en Verdana worden aanbevolen [12], en de lettergroottes zijn typisch 5 of 6 punten. Lange stukken tekst kan men moeilijk weergeven en worden dus beter vermeden. In tegenstelling tot bij digitale televisies kan men kleuren met


9

vertrouwen gebruiken; op elk toestel zal de kleur dezelfde zijn. De schermresolutie bedraagt 84×84 of 120×130 en de kijkafstand is ongeveer 30 cm. Hoewel geavanceerde mobiele telefoons nu in staat zijn om multimedia weer te geven, is het bekijken van een video op een mobiele telefoon niet zo populair en kan dit dus voorlopig beter vermeden worden. Voorlopig zijn nog geen smartcard lezers voor mobiele telefoons op de markt, dus authenticatie aan de hand van een elektronische identiteitskaart laat hier nog wat op zich wachten. Het key pad is het enige input apparaat, waarmee de gebruiker kan interageren met de applicatie. Voor het ingeven van tekst wordt het sms-principe gebruikt, waarbij een aantal keren een nummer moet ingetoetst worden om de juiste letter te verkrijgen. Dit vertraagt de interactie natuurlijk enorm . Daarom kan gekozen worden om bepaalde gegevens (zoals gebruikersnaam, paswoord) te cachen in het persistente geheugen van het toestel. Nadelen hiervan worden in het onderdeel Netwerkkarakteristieken besproken. Hardware karakteristieken Mobiele telefoons hebben zeer zeker te lijden onder geheugenbeperkingen (gemiddeld slechts 0.5 MB persistent geheugen en 0.2 MB RAM geheugen). Ook is de CPU snelheid stukken trager dan bij de processoren van computers. Een gevolg hiervan is, dat de applicatie zo klein mogelijk moet zijn wat de code betreft. Zware bewerkingen moeten deze keer aan de server-zijde plaatsvinden, en er kan maar met mate gecached worden. We merken op dat het persistent geheugen hier écht persistent is (in tegenstelling tot bij digitale televisie) en geen gegevens worden verwijderd zonder dat de applicatie dit gevraagd heeft. Applicatieontwikkelaars zullen er dus streng moeten op toezien dat alle ongebruikte gegevens verwijderd worden. De levensduur van de batterij, die enkele weken kan bedragen, is veel groter dan bij een laptop in stand-by modus. De anytime ” anywhere”-duur is hier dus veel groter. Netwerkkarakteristieken Het mobiel netwerk heeft dikwijls hoge latenties en een lage bandbreedte. De lage transfersnelheden zijn nog een extra reden om de applicatiegrootte te beperken. Zoals bij de telefoonmodemverbinding van computers is hier ook sprake van een onderbroken connectiviteit en kan dus geopteerd worden voor synchronisatie- en cashing-mechanismes. Het cachen van gebruikersnaam en paswoord is hier iets meer van toepassing, omdat meestal slechts één persoon de mobiele telefoon gebruikt. Anderzijds kan iemand, die het apparaat gestolen heeft, dan wel met de gegevens van de eigenaar zich aanmelden bij de dienst. Ook hier betaalt de gebruiker voor elke verbinding, die hij maakt met het netwerk. Daarom zal de applicatie de verbindingstijd moeten minimaliseren. Omwille van de trage verbinding en de kleine CPU snelheid van het apparaat zal het dikwijls langer duren om data van de server in te laden en te verwerken. De mobiele telefoon gebruiker verwacht echter constant te kunnen interageren met zijn toestel. Er zou dus zeker een wacht-boodschap moeten weergegeven worden met eventueel de mogelijkheid om de opdracht te onderbreken.


10

Algemene eigenschappen van het platform Mobiele telefoons worden enorm veel gebruikt overal ter wereld. Mensen zonder PDA of computer kunnen op deze manier toch toegang verkrijgen tot de dienst. Een belangrijke troef van mobiele telefonie is de stem-communicatie in twee richtingen. Dit is dus een prachtig medium voor vertaaldiensten of het aanleren van talen zoals reeds onderzocht werd in [8][9][10]. Een toepassing hiervan is het INLET project [11] dat een innovatieve dienst voor mobiele telefoons ontwikkelde om toeristen aan te moedigen wat Griekse woordjes te leren tijden de Olympische Spelen in Athene. Het systeem voorzag een aantal faciliteiten om handige Griekse zinnetjes te leren in verschillende categoriën. Gebruikers konden ook directe vertalingen krijgen van woorden uit om het even welke taal naar het Grieks. De mobiele telefoon wordt ook wel eens het personal companion device genoemd. Het is in tegenstelling tot de digitale televisie en de computer een persoonlijk apparaat, dat de gebruiker constant bij zich heeft. De gebruiker zal daardoor ook meer vertrouwen schenken aan dit medium en sneller tot kopen overgaan. Het toestel moet natuurlijk zijn oorspronkelijke functionaliteit blijven behouden: de gebruiker moet blijven telefoongesprekken kunnen ontvangen. Hier moeten de applicatieontwikkelaars ook rekening mee houden. Hoewel de gebruiker de applicatie zelden of nooit zal gebruiken in combinatie met een andere applicatie of in combinatie met telefoneren zal de focus van de gebruiker op de applicatie minder groot zijn dan bij een applicatie voor de computer. Dit komt omdat de gebruiker sneller van het kleine scherm afgeleid zal zijn door gebeurtenissen in zijn omgeving. Door het verminderd aantal inputapparaten is de interactie aan de ene kant flink verminderd ten opzichte van het computer-medium. Maar aan de andere kant is de interactiviteit ook gestegen. Zo kan een gebruiker, bijvoorbeeld bij het zien van een mooie wagen, onmiddellijk informatie opvragen en zelfs eventueel aankopen. Daarnaast zou een gebruiker, door het bijhouden van een gebruikersprofiel (zie hoofdstuk 5) de mogelijkheid hebben om alle promoties voor zijn profiel te bekijken, terwijl hij winkelt in een supermarkt. User interface, interactie en navigatie Een mobiele dienst zal normaal gezien het hele scherm innemen, een portrait-oriëntatie1 hebben en een grootte hebben van 2 op 3 cm. Snel na de ontwikkeling van de eerste applicaties voor dit platform zijn er relatief strenge conventies overeengekomen door de gebruikers en ontwikkelaars van de mobiele telefoons. Er ontstonden platform richtlijnen (platform guidelines) om het de gebruikers gemakkelijker te maken (zoals bijvoorbeeld in [12]). Applicaties, die niet voldoen aan deze voorwaarden, worden niet aanvaard door de platform providers. Een dergelijke richtlijn kan bijvoorbeeld zijn, dat geselecteerde items op het scherm gemarkeerd moeten zijn in een andere kleur. User interface ontwerpers zijn gelimiteerd tot een menu-gebaseerde interface. Hoewel menu items grafisch kunnen zijn in bepaalde moderne telefoons, zijn dit eigenlijk eerder grafische menu labels dan adresseerbare objecten, zoals men die kent vanop een computer desktop. Bij mobiele telefoonapplicaties worden eenvoudige navigatiestructuren aanbevolen. Verticale navigatie is gelimiteerd tot 2 of 3 niveaus en horizontale navigatie vindt soms plaats tussen bepaalde secties 1 Portrait-oriëntatie komt overeen met een staande oriëntatie en is het tegenovergestelde van een landscapeoriëntatie


11

of lange stukken tekst. Hyperlinks, dus verwijzingen vanaf individuele items in een tekst, worden zelden teruggevonden. Zoals eerder beschreven is mobiele telefoon interactie erg beperkt wegens de beperkte inputmogelijkheden. Bovendien zijn de key pads sterk verschillend naargelang het type mobiele telefoon, en gebruikt men ook andere conventies. Deze problemen, samen met de navigatie-restricties, zullen we ook terugvinden bij digitale televisie.

2.2.3

Digitale televisie

Digitale interactieve televisie biedt nieuwe faciliteiten voor het ontvangen van informatie en voor communicatie, inclusief de mogelijkheid om ondertiteling te optimaliseren. De functionaliteit, voorzien door iTV, is gelijkaardig aan deze van een eenvoudige web site, maar wordt weergegeven op het televisiescherm. Fysische karakteristieken Het traditionele tv-scherm heeft een aspect ratio van 4:3, en daarbinnen wordt een gebied van ongeveer 592×480 pixels beschouwd als veilig om weer te geven, i.e. het gebied waarin alle informatie zeker wordt weergegeven op het tv-scherm. Dit laat een grens-zone van ongeveer 10 % over, die veilig genoeg is voor achtergrondfiguren en dergelijke, maar niet voor kerninformatie. De minimale schermresolutie is 720×576. We treffen dus bij de verschillende platformen telkens verschillende resoluties aan. De content provider kan er dus goed aan doen bepaalde grafische content in verschillende resoluties op te slaan op de server voor de verschillende platformen. Zo zal een té gedetailleerde foto zinloos zijn voor een mobiele telefoon, terwijl een foto in te slechte kwaliteit wazig zal weergegeven worden op het computerscherm. De informatie op een tv-scherm wordt typisch gelezen vanop een afstand van 2 tot 3 meter. De ontwerper moet hiermee rekening houden bij het creëren van leesbare tekst. Vele broadcasters hebben het Tiresias lettertype aanvaard als standaard, maar Gill Sans, Zurich en andere Sans Serif lettertypes worden ook gebruikt, met een minimum grootte van 18 punten. Kleurencombinaties hebben een sterke impact op de leesbaarheid van het tv-scherm, waarbij hoog gesatureerde kleuren in combinatie met elkaar resulteren in seepage problemen2 . Omwille van de noodzakelijke lettergrootte en de gelimiteerde schermgrootte kunnen iTV diensten maar kleine hoeveelheden tekst weergeven op het scherm. Ook worden complexe of gedetailleerde figuren soms in een slechte kwaliteit of in verkeerde kleuren weergegeven op het tv- scherm. Effecten zoals vet of andere varianten kunnen ook onopgemerkt blijven. Hardware karakteristieken Digitale televisie heeft, weliswaar iets minder dan bij mobiele telefoons, ook te kampen met geheugenrestricties. Het persistente geheugen ligt tussen de 16 MB en 40 GB en het RAM geheugen is minstens 32 MB groot. De CPU snelheid ligt meestal tussen 233 en 333 MHz. We kunnen dus analoge conclusies trekken als bij mobiele telefoons: de applicatiegrootte moet geminimaliseerd worden en zware berekeningen moeten aan de server-zijde uitgevoerd worden. Het basis input apparaat is de remote control, dat kan aangevuld worden met een toetsenbord, 2 Seepage problemen hebben tot gevolg dat de gebruikers de content niet duidelijk kunnen waarnemen, een voorbeeld hiervan is bijvoorbeeld een witte tekst op een gele achtergrond


12

zodat de gebruiker niet telkens tekst moet ingeven op de sms-manier. Een ander extra input apparaat is de smartcard lezer, die in staat is om bijvoorbeeld gegevens van de elektronische identiteitskaart te lezen, zodat een gebruiker zich gemakkelijk kan authentiseren. In tegenstelling tot mobiele telefoons is het persistent geheugen hier niet echt persistent. Het kan gebeuren dat de set-top box gegevens, die opgeslagen zijn, plots verwijdert omwille van bijvoorbeeld geheugentekort. De applicatieontwikkelaar dient hiermee rekening te houden en zal data, indien noodzakelijk, dus direct aan de server-zijde moeten opslaan in plaats van deze enkel op de set-top box op te slaan. Ook is digitale televisie niet afhankelijk van de levensduur van batterijen en kan deze dus wel constant gebruikt worden. Met andere woorden: er is wel sprake van anytime, maar niet van anywhere. Netwerkkarakteristieken Op verschillende manieren kan communicatie gemaakt worden tussen de set-top box en de back-end tier (de server): via telefoonmodem, ADSL, breedband kabel,. . . We komen hierbij dus in eenzelfde situatie als bij het computer-platform. Afhankelijk van de type verbinding zal de applicatie andere faciliteiten moeten hebben. Enerzijds kan er door het groter persistent geheugen meer data gecacht worden, maar anderzijds kan het gebeuren dat deze gegevens plots verdwijnen uit de set-top box. Ook kan het principe van synchronisatie toegepast worden, zolang het niet persistent zijn van het persistente geheugen maar in het achterhoofd gehouden wordt. Ook bij digitale televisie verwacht de gebruiker geen lange wachttijden of vastlopende applicaties. Daarom moet, net zoals bij digitale telefoons, een wachtboodschap verschijnen met eventueel de mogelijkheid om de opdracht te onderbreken. De broadcast provider zou eventueel een onderscheid kunnen maken tussen voorgenoemde connectiemanieren (telefoonmodem, ADSL, breedband kabel) en op basis daarvan een verschillende applicatie kunnen leveren. Dit geldt ook voor computergebruikers en mobiele telefoongebruikers. Afhankelijk van de connectie krijgen ze een applicatie voorgeschoteld die aan hun netwerkkarakteristieken is aangepast. Zo zou een telefoonmodemgebruiker zo weinig mogelijk connectie moeten maken met de server. De mobiele telefoongebruiker, die tijdelijk geen toegang kan hebben tot het netwerk, zou de mogelijkheid moeten hebben om informatie tijdelijk persistent op te slaan om dan later de data te synchroniseren met de server, wanneer hij weer toegang heeft tot het netwerk. Algemene eigenschappen van het platform Enkele eigenschappen maken van gewone traditionele televisie al een krachtig medium. Het biedt een rijke multimedia ervaring: actueel en cultureel relevante video en audio worden aangeboden in een ontspannende omgeving. Via dit platform wordt ook een grote groep thuisgebruikers (zoals bejaarden en invaliden) aangetrokken die geen computer of mobiele telefoon hebben of er moeilijk mee overweg kunnen wegens te complex of een te klein scherm. Vanuit de luie zetel zou iedereen toegang kunnen krijgen tot bepaalde diensten, zoals bijvoorbeeld t-commerce. Door de sterke vertrouwdheid met dit medium zou de interactiviteit zeker zijn vruchten afwerpen. De gebruiker zou bijvoorbeeld, tijdens het bekijken van een film, bepaalde filmgadgets direct kunnen aankopen. of bij het zien van een reclamespotje zou de gebruiker extra informatie kunnen opvragen over de aangeboden producten. In de toekomst zal de digitale televisie (die dan ook chat, email, internet,. . . zal aanbieden) de computer waarschijnlijk


13

gedeeltelijk vervangen. We kunnen stellen dat veiligheid heel belangrijk is bij digitale televisie, mobiele telefoons en computers. Het vertrouwen van de klant mag niet geschaad worden, anders zal het succes ervan enorm dalen. Er zijn ook enkele nadelen verbonden aan digitale televisie. Eerst en vooral is televisie kijken een groepsgebeuren en is het geen personal companion zoals de mobiele telefoon. Voor de applicatie ontwerper betekent dit dat persoonlijke gegevens best niet persistent worden opgeslagen, nadat een gebruiker zich afgemeld heeft. Een voordeel hiervan is wel, dat familie-diensten, zoals het bekijken van een trailer van een gekozen film of het bekijken van de reisfoto’s, gezellig in groep kunnen gebeuren in een ontspannen, familiale sfeer. Het is vanzelfsprekend dat het televisietoestel zijn functionaliteit moet blijven behouden: men moet televisie kunnen kijken terwijl de applicitie geopend is en dit met zo weinig head downmomenten als mogelijk. Het wordt aangeraden de gebruiker niet te dwingen neer te kijken naar de remote control. Daarom repliceren de ontwikkelaars dikwijls de kleurknoppen en soms ook de numerieke knoppen op het scherm. User interface, interactie en navigatie Net zoals bij mobiele telefoons zijn gebruikers van iTV gelimiteerd tot een menu-gebaseerde interface. Verticale navigatie wordt beperkt in diepte en horizontale navigatie is mogelijk tussen bepaalde delen. Hyperlinks worden ook hier weinig gebruikt, omdat ze bijdragen tot complex navigatie, die alleen maar vertragingen met zich meebrengt. Tevens worden ze volgens de BBC ontwerprichtlijnen niet geapprecieerd door TV kijkers [13]. Interactieve kijkers kunnen met het scherm interageren op drie manieren: door navigatie, acties (zoals bijvoorbeeld indrukken van de ENTER-toets) of het editeren van tekst. Het toestel dat hiervoor gebruikt wordt, is de remote control, die altijd de vier kleurtoetsen zal bevatten: rood, groen, geel en blauw (in deze volgorde!). Soms neemt de applicatie het hele scherm in, waarbij dan mogelijks de audio stream behouden blijft. Een andere manier is om het videobeeld te herschalen (in de rechterbovenhoek). Dan wordt de informatie afgebeeld in een L-vorm rond het videobeeld. Ook kan de user interface op een semi-transparante laag gepresenteerd worden bovenop de full-screen video. De hoeveelheid informatie, die op het scherm kan afgebeeld worden is ongeveer dezelfde bij digitale televisie en mobiele telefoons. Er kan geprobeerd worden de content voor de mobiele telefoon op de iTV portrait-georiënteerd weer te geven, om zo het beeld van de mobiele telefoon te weerspiegelen. Zowel bij mobiele telefoon als bij digitale televisie worden strenge ontwerprichtlijnen voor de applicaties voorgeschreven door de content-providers. Hoewel deze richtlijnen niet altijd gelijklopend zijn voor beide platforms, moet men toch proberen het ontwerp op de verschillende apparaten zo consistent mogelijk te houden. Volgens [14] kan het weergeven van een merknaam of -symbool hierbij helpen. Problemen kunnen opduiken als de twee toestellen tegelijk gebruikt worden, omdat de kijker dan heen en weer moet kijken (tussen de digitale televisie en zijn mobiele telefoon), wat moeilijk is voor mensen die verziend of bijziend zijn.

2.3 De client zijde

2.3

14

De client zijde

Vanuit het standpunt van een ontwikkelaar kan een applicatie vele type clients ondersteunen die op verschillende toestellen draaien: laptops, desktops, palmtops, mobiele telefoons, digitale televisie,. . . Ze kunnen via een bedraad netwerk, via een draadloos netwerk of via een combinatie van beide een connectie maken met de applicatie server en dit over het bedrijfsnetwerk (intranet) of over het World Wide Web. Ze kunnen variëren van dun, browser-gebaseerd en server-afhankelijk tot dik, programmeerbaar en grotendeels zelfstandig. Vanuit het standpunt van een gebruiker is de client de applicatie. Ze moet nuttig, usable en responsief zijn. Omdat de gebruiker hoge verwachtingen heeft van de client moet de client strategie zorgvuldig gekozen worden. Zowel technische aspecten (zoals het netwerk) als niettechnische aspecten (zoals het doel van de applicatie) moeten grondig bestudeerd worden. Deze sectie presenteert richtlijnen voor het ontwikkelen en implementeren van clients.

2.3.1

Client overwegingen

Elke applicatie heeft eisen en verwachtingen, waaraan de client moet voldoen en die beperkt worden door de omgeving waarin de client werkt. De gebruikers en hun karakteristieken bepalen grotendeels welk soort client of interface gebruikt zal worden. Zo zijn desktop Web browsers populair voor e-mail en e-shopping, omdat ze een gekende interface hebben. Draadloze handheld clients zijn daarentegen nuttig voor verkoop on-the-field, omdat ze de mogelijkheid bieden realtime toegang te verkrijgen tot de bedrijfsgegevens van om het even waar. Eens men beslist heeft welk type client geschikt is, kan de client ontwikkeld worden met de netwerk-, beveiligings- en platformoverwegingen in het achterhoofd. Netwerkoverwegingen Clients kunnen op verschillende manieren toegang krijgen tot de bedrijfsgegevens. De quality of service (QoS) van deze manieren kan enorm variëren van excellent, wanneer een client binnen het bedrijfsnetwerk toegang verkrijgt, over matig, bij een telefoonmodem-verbinding, tot slecht, bij een draadloos netwerk. De connectiviteit kan ook variëren. Zo zijn intranet clients altijd geconnecteerd, terwijl mobiele clients onderbroken geconnecteerd zijn en meestal voor een korte duur. Onafhankelijk van de QoS die beschikbaar is, zou er altijd rekening mee moeten gehouden worden dat de client afhangt van een imperfect netwerk. Hoewel de client een stand-alone entiteit is, kan ze niet als één geprogrammeerd worden, omdat ze een deel is van een gedistribueerde applicatie. Drie eigenschappen van een netwerk vragen speciale aandacht: • de latentie is niet nul • de bandbreedte is eindig • het netwerk is niet altijd betrouwbaar Een goed ontworpen bedrijfsapplicatie, en meer specifiek de client, moet deze eigenschappen in rekening brengen. De ideale client connecteert enkel met de server wanneer dat noodzakelijk is, transfereert enkel zoveel data als nodig, en werkt behoorlijk goed wanneer ze de server niet kan bereiken. Later in deze sectie worden strategieën besproken om deze doelen te realiseren.

2.3 De client zijde

15

Beveiligingsoverwegingen Verschillende netwerken hebben diverse beveiligingseisen, die beperken hoe de client tot een bedrijf connecteert. Wanneer clients bijvoorbeeld connecteren over het internet, communiceren ze met servers via een firewall. De aanwezigheid van een firewall die niet onder de controle van de ontwikkelaar valt, limiteert de keuze van protocols die de client kan gebruiken. De meeste firewalls zijn geconfigureerd om HTTP door te laten, maar niet het internet Inter-Orb Protocol (IIOP). Deze eigenschap van firewalls maakt Web gebaseerde diensten, die gebruik maken van HTTP, aantrekkelijk in vergelijking met RMI- of COBRA-gebaseerde diensten, die IIOP gebruiken. De beveiligingsoverwegingen includeren ook de gebruikersauthenticatie. Wanneer de client en de server zich in hetzelfde beveiligingsdomein bevinden, wat het geval is in een bedrijfsnetwerk, kan de authenticatie van een gebruiker eenvoudig verlopen door hem één enkele keer te laten aanmelden om toegang te verkrijgen tot de bedrijfsgegevens. Dit staat bekend als single sign on. Wanneer de client en server zich in een verschillend beveiligingsdomein bevinden (bijvoorbeeld bij het aanmelden over het internet) is een betere aanmeldingsprocedure nodig, zoals degene die voorgesteld wordt door de Liberty Alliance [15]. Het authenticatieproces zelf moet betrouwbaar zijn, evenals de client-server communicatie die daarop volgt. Zowel aan de server-zijde als aan de client-zijde moeten mechanismes voorzien worden om deze betrouwbaarheid te garanderen. Platformoverwegingen De mogelijkheden van elk client platform be¨ınvloeden de ontwikkeling van een applicatie. Zo kan een browser client bijvoorbeeld geen grafieken genereren omtrent financiële informatie. Ze zou een server nodig hebben om de grafieken te renderen als figuren die dan gedownload kunnen worden. Een programmeerbare client daarentegen kan de financiële data zelf downloaden van de server en grafieken renderen in zijn eigen interface. Daarnaast moeten de fysische karakteristieken (zoals deze besproken in de vorige sectie) ook onder ogen worden genomen. Desktop computers hebben een groot scherm, een toetsenbord en een muis. Met dergelijke clients zijn gebruikers in staat veel informatie te bekijken en te manipuleren. Mobiele telefoons daarentegen hebben kleine schermen en hangen af van knopgebaseerde interacties (normaalgezien duim-bediend). Met zulke clients kunnen (en willen) gebruikers geen grote hoeveelheden data zien en manipuleren. Applicaties, die op meerdere platformen toegankelijk willen zijn, stellen bijkomende eisen. Het ontwikkelen van een client voor elk platform vraagt, naast de extra middelen voor implementatie, testen en onderhoud, ook gespecialiseerde kennis van elk platform. Soms kan het gemakkelijker zijn om één client te ontwikkelen voor alle platformen (een browser-gebaseerde oplossing bijvoorbeeld). Een nadeel daaraan is dat de voordelen, die uniek zijn aan elk platform, op die manier niet optimaal benut kunnen worden.

2.3.2

Algemene richtlijnen voor het ontwerp van clients

Ontwerpers worden aangeraden om een dunne client (thin client) architectuur te gebruiken. Dit wil echter niet zeggen dat de clients dan dom zijn, maar ze kunnen instaan voor volgende verantwoordelijkheden:

2.3 De client zijde

16

• het presenteren van de gebruikersinterface: De logica achter het presenteren van de data aan de gebruiker kan ofwel geprogrammeerd worden op de client ofwel gedownload worden van de server. • het valideren van de gebruikersinputs: Hoewel de server-zijde instaat voor de correctheid van de data, kan de client de gebruikersinputs ook al valideren. • beheer van de conversationele toestand: Applicaties moeten informatie bijhouden, terwijl een gebruiker een conversatie heeft met de server. De client kan ofwel geen, ofwel sommige, ofwel alle informatie bijhouden die bekend staat als conversationele toestand. Afhankelijk van de inspanningen die men wil leveren bij het ontwikkelen van de client, de applicatie’s performantie en de gebruikerservaring zullen deze verantwoordelijkheden zwaarder of minder zwaar doorwegen. Hoe meer verantwoordelijkheden aan de client-zijde gelegd worden, hoe efficiënter ze zal zijn. In de secties 2.3.3 en 2.3.4 worden browser en Java clients apart behandeld. Het is niet verplicht om ofwel de ene te nemen, ofwel de andere. Een applicatie kan tegelijk browsers én Java clients bedienen. Zo heeft de Java Pet Store applicatie van Sun (dit is een online dierenwinkel waarover meer informatie te vinden is in [16]) een Web browser interface voor de kopers en een Java client voor de administrators.

2.3.3

Richtlijnen voor browser clients

Browsers zijn de dunste clients. Ze presenteren data aan hun gebruikers en hangen van servers af voor de functionaliteit van de applicatie. Ze zijn aantrekkelijk omwille van een aantal redenen. Eerst en vooral moeten ze bijna nooit ge¨ updatet worden. Wanneer een applicatie verandert, moet de server-zijde code veranderd worden, terwijl de browsers dezelfde blijven. Ten tweede zijn ze ook alomtegenwoordig. Bijna elke computer heeft een Web browser, mobiele toestellen hebben een microbrowser en digitale televisie kan ook voorzien worden van een browser. Het presenteren van de gebruikersinterface Browser clients downloaden documenten van een server. Deze documenten bevatten zowel de data zelf als instructies om de data weer te geven. De documenten worden meestal dynamisch gegenereerd door JSP pagina’s (en minder vaak door Java servlets) en zijn geschreven in een presentatie markup taal zoals HTML (Hypertext Markup Language). Een presentatie markup taal laat één enkel document toe een verschillende presentatie te bieden afhankelijk van de browser die het presenteert (Web browser, microbrowser,. . . ). Er zijn andere alternatieven voor HTML, waarvan de presentatie verschillend is van deze bij de traditionele Web browsers. Enkele voorbeelden zijn Wireless Markup Language (WML), Compact HTML (CHTML), Extensible HTML (XHTML), Voice Markup Language (VoiceML) en DVB-HTML. Deze laatste Markup Language, DVB-HTML, zullen we in het kader van deze thesis, later wat meer in detail bestuderen. Naar analogie met Web browsers, zoals Microsft Internet Explorer of Mozilla Firefox, zochten we naar browsers voor andere platformen. X-Smiles [17] is een Java gebaseerde XML browser bedoeld voor ingebedde systemen, zoals PDA’s, mobiele telefoons en set-top boxen (STB’s). De

2.3 De client zijde

17

browser ondersteunt onder andere SMIL, SVG, XForms, XML Events, XSL FO en XHTML. Zo draait de eerder vermelde platform-onafhankelijke SMIL player uit [3] op deze browser. Browsers hebben enkele sterktes, die hen tot veelgebruikte bedrijfsapplicatie clients maken. Eerst en vooral bieden ze een gekende omgeving voor de gebruiker. Browsers worden overal gebruikt en de interactie die ze bieden, is over het algemeen dezelfde. Dit maakt browsersapplicaties vooral populair bij nieuwe gebruikers. Browser applicaties zijn bovendien gemakkelijk te implementeren. De markup talen die browsers gebruiken, representeren een hoog abstractieniveau van gepresenteerde data, waarbij de presentatie en event-handling mechanismen overgelaten worden aan de browser. De trade-off, die ontstaat bij het gebruik van markup talen, wordt gecreëerd door het feit dat markup talen slechts gelimiteerde interactie toelaten. Zo laten HTML tags enkel presentaties en interacties toe, die zinvol zijn voor hypergelinkte documenten. Dit kan lichtjes verbeterd worden door gebruik te maken van technologieën zoals JavaScript, in combinatie met andere standaarden zoals CSS en DOM. Men moet er wel rekening mee houden dat de ondersteuning voor deze documenten, ook wel gekend als Dynamic HTML (DHTML) documenten, inconsistent is onder verschillende browsers, zodat het creëren van een draagbare (portable) DHTML gebaseerde client moeilijk is. Een belangrijker nadeel van het gebruik van browser clients is de potentieel lage antwoordtijd. De client hangt af van de server voor de presentatielogica en moet dus connecteren met de server telkens zijn interface verandert. Vervolgens maken browser clients vele connecties tot de server, wat een probleem is als de latentie hoog is. Daarenboven zijn de antwoorden aan de client groot en verbruiken ze veel bandbreedte, omdat ze presentatie logica bevatten die vermengd is met de data. DVB-HTML In hoofdstuk 3 zullen we het Multimedia Home Platform (MHP) bespreken, dat gebruikt wordt voor de ontwikkeling van applicaties voor de digitale televisie. MHP specificatie 1.1 definieert, in toevoeging tot het DVB-J formaat (voor het construeren van Java clients, ook wel Xlets genaamd), een nieuw formaat genaamd DVB-HTML. Het idee achter DVB-HTML is om internet gebaseerde diensten te bieden (Web browsers, e-mail,. . . ) en internet-gebaseerde content voor te kunnen stellen op het MHP-platform. De voordelen hiervan zijn enorm: • content providers diversifiëren hun doelplatformen: computer, mobiele telefoons, PDA, iTV,. . . , Het laat hen toe gemeenschappelijk content te creëren met behulp van reeds bestaande content management systemen (CMS) • eenvoudige applicaties, waarbij hoofdzakelijk aan presentatie wordt gedaan, kunnen sneller geschreven worden • reeds bestaande content van het Web kan gemakkelijk herbruikt worden De term DVB-HTML is wat misleidend, want DVB-HTML is eigenlijk gebaseerd op XML 1.0. XML is een metataal die gebruikt wordt voor de definitie van markup gebaseerde talen. De syntactische en grammaticale regels van een XML taal worden beschreven in een Document Type Definition (DTD). De DVB-HTML DTD wordt gepresenteerd in de MHP 1.1 specificatie. Ze is gebaseerd op XHTML die overeen komt met W3C HTML 4.0. Waarom is DVB-HTML nu niet volledig XHTML 1.0 of HTML 4.0? Het antwoord hierop is dat deze formaten voornamelijk voor PC ontworpen zijn en niet voor tv-omgevingen, waar de

2.3 De client zijde

18

layout- en interactiemechanismes compleet anders zijn. Daarom werden enkele W3C HTML 4.0 modules aangepast voor het televisieplatform, andere modules werden weggelaten en één module (DVB Intrinsic Events) werd toegevoegd. Omwille van interoperabiliteitsredenen moeten DVB-HTML documenten écht voldoen aan de regels die uitgedrukt zijn in de DVB-HTML DTD. Dit staat in contrast met de huidige Web browsers, die niet helemaal overeenstemmen met de W3C specificaties. Dezelfde content zal zelden hetzelfde uiterlijk hebben op verschillende Web browsers zoals Microsoft Internet Explorer en Mozilla Firefox. Daar worden niet-ondersteunde opdrachten eenvoudig genegeerd. DVBHTML daarentegen eist de validatie van elk document dat van het DVB-HTML type is. Een document dat een regel uit de DVB-HTML DTD verbreekt, is ongeldig en zal dus niet uitgevoerd worden en geweigerd worden door het MHP-platform. Omwille van zijn XML aard kan DVBHTML gemakkelijk verwerkt en weergegeven worden op elke Web browser, hoewel het resultaat hiervan niet voorspelbaar is. Het omgekeerde daarentegen is niet waar: Web content, die niet aan de DVB-HTML standaard voldoet, zal geweigerd worden op het MHP-platform. In de huidige situatie (gebruik makende van MHP 1.0) moet een MHP-applicatie een DVB-J applicatie (Xlet) zijn, die geprogrammeerd is met behulp van de MHP 1.0 Java API. Maar in de nabije toekomst, wanneer DVB-HTML wel beschikbaar zal zijn op MHP set-top boxen, kan een MHP-applicatie ook een DVB-HTML applicatie zijn, die ge¨ınterpreteerd wordt door een DVB-HTML interpreter of browser op een MHP set-top box. Een groot nadeel van deze veelbelovende DVB-HTML technologie is dat ze niet verplicht ondersteund moet worden door toekomstige set-top boxen. Het ontbreken van DVB-HTML op dit moment betekent dat elke applicatie individueel geprogrammeerd moet worden. Dit proces resulteert in een applicatie-optimale implementatie met een applicatie-optimale performantie. Daarentegen vraagt het ontwikkelen veel meer tijd en werk. Bovendien zullen de transmissiebandbreedte en -kosten veel hoger liggen, omdat elke gebruikersapplicatie verstuurd moet worden naar de MHP set-top box. Bovendien includeert MHP 1.0 geen enkele formaatspecificatie voor content (zoals tekst, nieuws,. . . ), behalve die voor het presenteren van figuren bij DVB-J applicaties. De consequentie is dat elke applicatie zijn content ontvangt in een eigen formaat. Er zal geen enkele operabiliteit bestaan tussen de content van twee verschillende applicaties die gebroadcast worden. Daardoor zijn ook eigen content management systemen nodig voor elk eigen content formaat. Dit kan aanvaardbaar zijn voor applicaties die veel complexe transacties bevatten en minder content, maar het is een verspilling van werk en tijd voor meer push-georiënteerde informatie diensten zoals super teletext, tickers, magazines, t-commerce,. . . Voor deze applicaties zou het gebruik van een universele interpreter of browser, die ge¨ımplementeerd wordt als een DVB-J applicatie die DVB-HTML interpreteert of een deelverzameling daarvan, een meer elegante en kost besparende manier zijn. De voordelen van dergelijke aanpak zijn duidelijk: • het gebruik van reeds bestaande content management systemen voor HTML/XML applicaties • het gebruik van reeds bestaande content van het Web, weliswaar met kleinere hoeveelheden weergegeven op het scherm • éeén enkele applicatie (de browser zelf) zal actief zijn op de set-top box voor verschillende tv-diensten

2.3 De client zijde

19

• het is een investering in toekomst-gerichte DVB-HTML content in plaats van eigen content types, die ge¨ınterpreteerd worden door eigen applicaties en eigen content management systemen nodig hebben Al deze voordelen zullen resulteren in besparing van tijd, geld en bronnen. In figuur 2.1 wordt de architectuur voorgesteld van een DVB-HTML browser die als een DVB-J applicatie ge¨ımplementeerd is. De originele gelaagde MHP-architectuur wordt voorgesteld in figuur 2.2, waarbij verschillende applicaties nodig zijn om verschillende diensten aan te bieden. De commerciële applicaties Pontegra en Ortikon, die verder besproken zullen worden in hoofdstuk 4 maken gebruik van dit principe en implementeren een eigen browser, die een deelverzameling van DVB-HTML interpreteert. Voor verdere informatie over het DVB-HTML formaat verwijzen kan de lezer verwezen worden naar The Interactive TV Web [18]. EPG content

Spel content

Nieuws content

…

DVB-HTML browser Tuner

MHP Implementatie & API

Conditionele Toegang

Java Virtuele Machine

MPEG-decoder

Display

Besturingssysteem Drivers Hardware

Figuur 2.1: Een browser applicatie bovenop de MHP-architectuur

Het valideren van de gebruikersinputs We bekijken als voorbeeld een HTML formulier met velden voor kredietkaartgegevens die ingevuld moeten worden om een bestelling door te voeren. Een browser kan zelfstandig niet alle ingegeven data controleren, maar kan wel reeds enkele eenvoudige heuristieken uitvoeren om de data te valideren. De browser kan controleren of de naam van een kaarthouder niet null is en of het kredietkaartnummer het juiste aantal cijfers heeft. Wanneer de browser dit heeft gecontroleerd, kan ze de informatie doorsturen naar de server. Deze kan de data met krachtiger middelen controleren: controleren of de naam correspondeert met het ingegeven kaartnummer, controleren of er nog genoeg krediet op de rekening staat,. . . Wanneer een HTML browser client gebruikt wordt, kan voor het valideren van de gebruikersinput de JavaScript taal gebruikt worden. We merken op dat JavaScript implementaties lichtjes

2.3 De client zijde

20

MHP applicaties Spel

Nieuws

…

Tuner

MHP Implementatie & API

Conditionele Toegang

Java Virtuele Machine

MPEG-decoder

Display

Besturingssysteem Drivers Hardware

Figuur 2.2: De gelaagde MHP-architectuur variëren van browser tot browser. Om meerdere browsers te ondersteunen zal dus JavaScript code gebruikt moeten worden die op alle browsers werkt. Het valideren van user inputs door een browser verbetert niet noodzakelijk de antwoordtijd van de applicatie. Hoewel de validatie toelaat direct eenvoudige fouten te rapporteren, verbruikt de client meer bandbreedte, omdat het de bijkomende validatiecode moet downloaden samen met het HTML formulier. Voor een niet-triviaal formulier kan deze hoeveelheid validatiecode beduidend groot zijn. Om de downloadtijd te verminderen kunnen dikwijls gebruikte validatiefuncties in een apart bronbestand opgeslagen worden. Een browser kan dit bestand opslaan in zijn cache geheugen, zodat het niet opnieuw gedownload hoeft te worden bij een volgend gebruik van de validatiecode. Merk op dat, bij het implementeren van de browser validatie logica, sommige server-zijde validatie logica gedupliceerd wordt. De server-zijde is namelijk verplicht de data te valideren, terwijl de client-zijde validatie een optimalisatie is: het verbetert de gebruikerservaring en vermindert de load. Daarom zou de server de client nooit mogen vertrouwen wat dataconsistentie betreft. Beheer van de conversationele toestand Omdat HTTP een aanvraag-antwoord protocol is, worden individuele aanvragen onafhankelijk behandeld. Vervolgens hebben Web gebaseerde bedrijfsapplicaties nood aan een mechanisme voor het identificeren van een client en de toestand van de conversatie die ze hebben met de server. Een sessie is een korte opeenvolging van aanvragen door een gebruiker, die gebruik maakt van één enkele client om toegang te krijgen tot de dienst. De sessietoestand is de informatie, die door de sessie wordt bijgehouden gedurende de verschillende aanvragen. Zo gebruikt bijvoorbeeld een winkelwagentje een sessietoestand om bij te houden welke items uit de cataloog geselecteerd werden door de gebruiker. Browsers hebben twee mechanismes voor het cachen van een sessietoestand: cookies en URL rewriting.

2.3 De client zijde

21

• Een cookie is een kleine hoeveelheid data die door de server verstuurd wordt om opgeslagen te worden op de client. Telkens de client informatie zendt naar de server includeert ze in de aanvraag de headers van alle cookies die ze reeds ontvangen heeft van de server. Spijtig genoeg is cookie ondersteuning vrij inconsistent doordat, gebruikers cookie ondersteuning uitschakelen, firewalls en gateways ze filteren en sommige browsers ze niet ondersteunen. Ook kunnen er maar kleine hoeveelheden data in een cookie opgeslagen worden. Om draagbaar te zijn over alle browsers zou een cookie maximaal 4 kB mogen gebruiken. • URL rewriting houdt het encoderen in van de sessietoestand in een URL. Als de gebruiker dan een aanvraag maakt aan de URL, wordt de sessietoestand teruggestuurd naar de server. Deze techniek werkt bijna overal en kan een goede oplossing zijn als cookies niet kunnen gebruikt worden. Een nadeel hiervan is dat pagina’s, die herschreven URL’s bevatten, meer bandbreedte verbruiken. Voor elke aanvraag die de server ontvangt, moet ze elke URL herschrijven in zijn antwoord (de HTML pagina), die doordoor telkens groter wordt. Zowel cookies als pagina’s die herschreven URL’s bevatten, zijn kwetsbaar voor ongeautoriseerde toegang. Browsers houden cookies en pagina’s gewoonlijk bij in het lokale bestandssysteem, zodat alle gevoelige informatie (paswoorden, contactinformatie, kredietkaartnummers,. . . ) die ze bevatten, kwetsbaar is voor misbruik door iemand anders die toegang heeft tot de data. Het encrypteren van de opgeslagen data kan dit probleem oplossen. Een veel betere oplossing is dat clients geen sessietoestand moeten bewaren. In plaats daarvan zou de server de sessietoestand kunnen bijhouden. De server zendt dan telkens bij zijn antwoord (door gebruik te maken van cookies of URL rewriting) een sleutel, die correspondeert met de sessietoestand van de gebruiker. Daarop zal de browser deze sleutel ook terugsturen naar de server wanneer ze de sessie data wil gebruiken. Als de browser bijkomende informatie (naast de sessie sleutel) zou willen bijhouden (cachen), zou dit beperkt moeten blijven tot de gebruiker’s login en voorkeurinstellingen om zo de veiligheid te garanderen.

2.3.4

Richtlijnen voor Java clients

Java clients kunnen onderverdeeld worden in verschillende categoriën: applicaties, applets, MIDlets en Xlets zijn de belangrijkste. In hoofstuk 3 zullen we de werking van dit soort Java clients meer in detail bestuderen. Hier beperken we ons tot het geven van richtlijnen voor het ontwerp van Java clients. Voor een gedetailleerde uitwerking van alle richtlijnen verwijzen we de lezer naar [19][20]. Strategisch gezien is het altijd beter eerst een applicatie te ontwerpen alvorens te beginnen programmeren. Het corrigeren van code, wegens het vooraf niet stilstaan bij bepaalde gotcha’s, kan een pijnlijk proces zijn. Voor toestellen met sterke hardware restricties, zoals een mobiele telefoon of digitale televisie, kunnen we volgende algemene richtlijnen geven: • Houd het eenvoudig: verwijder onnodige functionaliteiten. Eventueel kan een onafhankelijke tweede applicatie gemaakt worden, die deze bijkomende functionaliteiten realiseert. • Hoe kleiner, hoe beter: kleinere applicaties gebruiken minder geheugen op het toestel en hebben een kleinere installatietijd. Overweeg om de Java applicatie te comprimeren als Java Archive (jar) files.

2.3 De client zijde

22

• Minimaliseer het run-time geheugen gebruik: gebruik scalaire types in plaats van object types, laat de applicatie niet afhangen van de garbage collector (maar beheer het geheugen zelf door object referenties, die niet meer gebruikt worden, de waarde null te geven), alloceer enkel objecten als dit effectief nodig is,. . . Andere manieren om het geheugengebruik op kleine toestellen te verkleinen is door snel bronnen vrij te geven, objecten te hergebruiken en excepties te vermijden. In geval we te maken hebben met mobiele apparaten kunnen we volgende basisrichtlijnen meegeven. • Laat de server het meeste werk doen: verplaats de rekenintensieve taken naar de server zijde om ze daar uit te voeren. Laat het mobiele toestel de interface beheren en kleine taken uitvoeren, terwijl de server het intensieve werk doet. Hierbij speelt het type mobiele toestel een rol in betrekking tot hoe gemakkelijk en hoeveel een toestel kan connecteren tot een server. • Kies de programmeertaal voorzichtig: J2ME (Java 2 Platform, Micro Edition), dat wordt besproken in hoofdstuk 3 is nog in zijn beginfase en is mogelijks niet de beste optie. Andere object-georiënteerde talen zoals C++ kunnen een beter keuze zijn, afhankelijk van de vereisten. Tot slot geven we nog enkele algemene richtlijnen mee omtrent de performantie van de applicatie. • Gebruik lokale variabelen: er kan sneller toegang verkregen worden tot lokale variabelen dan tot variabelen in andere klassen. • Vermijd string-samenvoegingen: ze verminderen de performantie en kunnen het geheugengebruik van de applicatie verhogen. • Gebruik draden en vermijd synchronisatie: elke operatie, die meer dan 0.1 seconde nodig heeft, moet uitgevoerd worden in een aparte draad (Eng.: thread). Het vermijden van synchronisatie kan de performatie ook verbeteren. • Maak gebruik van het Model-View-Controller (MVC) patroon: de gegevens (model ) worden gescheiden van de voorstelling van de informatie (view ). De controller is verantwoordelijk voor het gedrag van de applicatie. Op basis van een gebruikersactie past hij de toestand van de applicatie (model ) aan en selecteert hij de juiste presentatie (view ) voor de gebruiker. Het model bevat de toestand van de applicatie en bepaalt de toegang tot de gegegevens. De functionaliteit van de applicatie, de structuur van de gegevens en de bewerkingen op die gegevens maken deel uit van het model. De view of presentatie toont de inhoud van het model. Hoewel het gebruik van een MVC-architectuur aan de client-zijde de hoeveelheid code kan vergroten (vooral in de controller, omdat deze de applicatie flow implementeert), is het aantal voordelen toch wel opmerkelijk groter. – De applicatie flow wordt ge¨ısoleerd gehouden van de data en de presentatie. Hierdoor moeten ontwikkelaars enkel de controller bestuderen om de werking van de client te begrijpen. Zo kan ook de applicatie flow gemakkelijk aangepast worden zonder veranderingen te moeten doorvoeren aan het model of de presentatie.

2.3 De client zijde

23

– De data zijn afgescheiden van de presentatie. Grafische ontwerpers kunnen het uiterlijk van de client aanpassen zonder het model te moeten veranderen. – De presentatie is onafhankelijk van hoe de data worden opgeslagen. De presentatie wordt niet be¨ınvloed door de manier waarop het model de data beheert. Het model kan de data opvragen uit lokale variabelen of objecten, van een server door gebruik te maken van een HTTP-verbinding, van een cache in het persistent geheugen, of van een combinatie van voorgaande. Het presenteren van de gebruikersinterface Hoewel een Java client de gebruikersinterface van de applicatie bevat, kan de presentatie logica achter deze interface ofwel van een server komen (zoals bij een browser), ofwel geprogrammeerd worden in de clients. We zullen ons echter toespitsen op het tweede geval. Het implementeren van de gebruikersinterface vraagt meestal meer moeite dan het implementeren van een browser interface, maar de voordelen ervan zijn talrijk. Eerst en vooral bieden Java client interfaces een rijkere gebruikerservaring. Met programmeerbare GUI componenten kunnen meer natuurlijke interfaces gecreëerd worden. Daarnaast is de antwoordtijd van de applicatie bij Java clients veel kleiner dan bij browser clients omdat ze volledig naar eigen wensen geprogrammeerd kunnen worden. Wanneer een Java client en een browser client dezelfde data aanvragen, zal de Java client minder bandbreedte verbruiken. Wanneer bijvoorbeeld een browser een lijst bestellingen vraagt en een Java client identiek dezelfde lijst opvraagt, zal het antwoord langer op zich laten wachten bij de browser, omdat ze hier bijkomende presentatie logica bevat. De Java client daarentegen ontvangt de data en niets meer. Java clients kunnen ook geprogrammeerd worden om minder verbindingen tot een server te maken dan een browser. Zo kan bij een bepaalde applicatie de gebruiker de data bekijken gesorteerd volgens datum, prijs,. . . De Java client kan dit echter presenteren op basis van dezelfde verzameling data. Eenmaal ze deze data ontvangen heeft, moet ze niet nogmaals een verbinding maken met de server, tenzij ze de data wil vernieuwen. Een browser client daarentegen moet, telkens hij de data anders wil presenteren, verbinding maken met de server. Zelfs als de data niet veranderen, moet de browser de volgende pagina downloaden, omdat de data en de presentatie samen geleverd worden. Het valideren van de gebruikersinputs Net zoals de presentatielogica kan de input validatie logica ook geprogrammeerd worden op Java clients (ook wel smart clients genoemd), die meer mogelijkheden hebben dan browser clients. Browser clients moeten het voordeel van een kleiner aantal connecties (door slechte inputs te detecteren voor ze naar de server worden doorgestuurd) afwegen tegen de kost voor het hoger bandbreedtegebruik (voor het downloaden van de validatiecode van de server). Java clients daarentegen realiseren een meer efficiënte interface, omdat ze de validatie logica niet van de server moeten downloaden. Bij Java clients is het ook stukken eenvoudiger om input validatie logica te schrijven. Natuurlijk is de beste manier om client-zijde validatiecode te reduceren het onmogelijk maken ongeldige data in te geven. Zo is het weergeven van een tekstveld voor het ingeven van een

2.3 De client zijde

24

datum geen zo’n goede keuze en kan beter een drop-down menu gecreëerd worden, waarbij de gebruiker de dag, maand en het jaar kan kiezen. Om ook nog te vermijden dat bijvoorbeeld 30 februari wordt ingegeven, kan gebruik gemaakt worden van een intelligente kalender, die nagaat of de datum geldig is. Het is duidelijk dat een dergelijke component enkel mogelijk is bij Java clients. Beheer van de conversationele toestand Waar browser clients een robuust mechanisme aan de server-zijde moeten hebben voor het onderhouden van de sessietoestand, kunnen Java clients de sessietoestand op zichzelf beheren, omdat ze grotere hoeveelheden data kunnen cachen en manipuleren in het persistente geheugen. Vervolgens hebben Java clients de mogelijkheid verder te functioneren, terwijl ze gedisconnecteerd zijn. Dit is een uitstekende zaak wanneer de latentie hoog is of wanneer elke connectie opmerkelijk veel bandbreedte kost. Om een werking te ondersteunen met onderbroken connectie moet een Java client genoeg bruikbare data ontvangen voor hij weer offline gaat. De initiële kost voor het downloaden van die data kan hoog zijn, maar deze kost kan gereduceerd worden door de te downloaden data te beperken. Dit kan door de data op de server te filteren volgens gebruikersvoorkeuren of ingegeven zoekwoorden van de gebruikers. Vele applicaties voor mobiele toestellen gebruiken dergelijke strategieën. De Java Smart Ticket Demo bijvoorbeeld, die besproken wordt in hoofdstuk 6, maakt het een gebruiker mogelijk filmlijsten te downloaden op zijn mobiele telefoon. Om de data te reduceren zouden gebruikers een bepaald criterium, zoals het filmgenre of de postcode van de filmzaal, kunnen meegeven. Gebruikers kunnen dan bladeren in de gepersonaliseerde lijsten op hun telefoon, zonder te moeten connecteren met de server tot op het moment dat ze tickets willen aankopen. Merk op dat filmlijsten goede kandidaten zijn voor persistente opslag op de client, omdat ze niet dikwijls vernieuwd worden (misschien eenmaal per week). MIDlet clients (zoals deze bij de Java Smart Ticket Demo) kunnen de MIDP Record Management Store (RMS) API gebruiken om data lokaal op te slaan. Applicatie clients daarentegen kunnen ofwel lokale bestanden gebruiken (met de veronderstelling dat ze die permissies hebben) ofwel het Java Native Launching Protocol (JNLP) voor persistente opslag citejnlp. Applets hebben een zeer beperkte lokale opslag, omdat ze normaal een browser’s cookie opslagplaats gebruiken, hoewel ze ook de toelating kunnen vragen om lokale bestanden te schrijven. Voor Xlet clients voorziet het org.dvb.io package verschillende klassen voor de ondersteuning van persistente opslag. Voor meer informatie hierover verwijzen we naar [22]. We wijzen er nogmaals op dat het persistente geheugen van de set-top box om het even wanneer data kan verliezen en dat de ontwikkelaar hier rekening moet mee houden. In het geval van digitale televisie is er naast het opslaan van de informatie op de set-top box en het afhalen van de informatie van de server nog een derde mogelijkheid: de data laten meesturen in de caroussel stream. Zo kan ervoor gekozen worden om alle content van de applicatie al mee te sturen in de caroussel stream in plaats van deze achteraf te moeten halen van de server. Als de contenthoeveelheid te groot wordt, zal slechts een beperkte hoeveelheid content gebroadcast kunnen worden in de caroussel stream. Er kan voor gekozen worden om de meest populaire content op deze manier ter beschikking te stellen, terwijl minder populaire gegevens van de server gehaald moeten worden. We merken op dat de gegevens, die meegestuurd worden in

2.3 De client zijde

25

de carrousel, identiek zijn voor alle iTV gebruikers en niet afhankelijk zijn van gebruiker tot gebruiker zoals informatie die via het return path van de server wordt gehaald. Het voorgaande voorbeeld van het downloaden van filmlijsten illustreert een read-only interactie. De client ontvangt data van de server, cacht deze data en past de gecachte data later niet aan. Het kan gebeuren dat de Java client de data, die ze gekregen heeft van de server, moet actualiseren en dit moet rapporteren aan de server. Om ongeconnecteerd te blijven moet de gebruiker de updates lokaal in een wachtlijn zetten en enkel de updates doorsturen als de client connectie maakt met de server. Als voorbeeld geven we het reserveren van zetels voor een bepaalde film bij de Java Smart Ticket Demo. Wanneer de gebruiker beslist heeft welke film hij wil zien, downloadt de client de data die de zitplaatsen voorstellen en worden deze weergegeven op het scherm. Op het plan wordt aangeduid welke zetels nog beschikbaar zijn en welke reeds bezet zijn. Dit voorbeeld verduidelijkt twee belangrijke zaken. Ten eerste, wanneer Java clients bedrijfsdata manipuleren, moeten ze informatie krijgen over het model, maar ook over de bedrijfsregels (business rules) die op dat model van toepassing zijn. Zo moet de client het concept van bezette en beschikbare zetels verstaan en dat modelleren zoals de server dat doet. De client moet het dus onmogelijk maken voor gebruikers om reeds gereserveerde zetels te boeken, omdat dit tegen de bedrijfsregels in gaat. Ten tweede, wanneer Java clients bedrijfsdata manipuleren moeten applicaties schema’s voor datasynchronisatie implementeren. Een gebruiker kan bijvoorbeeld, gedurende de tijd dat een andere gebruiker het zitplan downloadt en beslist welke zetels hij wenst te reserveren, één van die zetels gereserveerd hebben. De applicatie heeft regels en mechanismen nodig om dergelijk conflict op te lossen. Bij de Smart Ticket Demo halen, in voorgaand geval, de data van de server het van de data van de client, omdat de bedrijfsregels beslissen dat degene die de tickets eerst bestelt de tickets ook verkrijgt. Een oplossing is is om het zitplan regelmatig te vernieuwen. Verschillende draden voor lange operaties Omdat netwerkoperaties en bepaalde operaties op het lokale geheugen een lange tijd kunnen innemen, zouden ontwikkelaars dit type operaties moeten uitvoeren in een aparte draad (thread). Nemen we als voorbeeld een operatie die uitgevoerd wordt doordat een gebruiker een knop heeft ingedrukt. Na het starten van deze operatie zou onmiddellijk moeten teruggekeerd worden naar de controller, omdat de applicatie anders een deadlock risceert. Het komt er dus op neer dat elke dergelijke operatie in een draad uitgevoerd zou moeten worden. Progressie-indicatoren voorzien Omdat netwerkoperaties een lange tijd kunnen duren, zouden applicaties feedback moeten geven over de vooruitgang van de operatie. Daarom zouden langere operaties een progressie-indicator kunnen weergeven, die aanduidt hoe snel de transactie vordert. Maak operaties onderbreekbaar Door gebruikers de mogelijkheid te geven lange operaties te onderbreken blijven ze de controle behouden over de applicatie. Progressie-indicatoren zouden een optionele stop-knop kunnen

2.4 De server zijde

26

weergeven, waarbij onmiddellijk naar het voorgaande scherm wordt teruggekeerd als deze ingedrukt wordt. Merk op dat niet alle operaties onderbreekbaar zouden mogen zijn, in het bijzonder operaties die meerdere afhankelijkheden hebben. Het is bijvoorbeeld aan te raden geen operaties te onderbreken die een gebruikersaccount creëert op de server en ook een deel van de account opslaat op de client. De twee voorgaande taken zouden ofwel allebei moeten plaatsvinden ofwel helemaal niet. Als de operatie toch onderbroken zou worden, zou inconsistentie kunnen ontstaan tussen de data aan de client-zijde en de data aan de server-zijde. De applicatie personaliseren Het concept personalisatie verwijst naar de mogelijkheid om een dienst aan te passen aan de informatie die men heeft over een gebruiker. Veel informatie over een gebruiker, zoals bijvoorbeeld zijn of haar adres, postcode,. . . verandert niet van sessie tot sessie en kan dus gebruikt worden om de applicatie te personaliseren. In hoofdstuk 5 worden profielbeheer en het personaliseren van een applicatie meer in detail behandeld. In tegenstelling tot de sessietoestand, die transient kan voorgesteld worden, zijn gepersonaliseerde data persistent. De keuze is aan de ontwikkelaar om te beslissen, waar de gepersonaliseerde data persistent worden opgeslagen. Ontwikkelaars moeten overwegen of de gepersonaliseerde data bruikbaar zijn voor verschillende types client. Zo kan de gebruiker zich aanmelden bij de applicatie via een handheld, via een web client, via digitale televisie,. . . Bepaalde informatie (zoals de voornaam en leeftijd bijvoorbeeld) zal telkens dezelfde zijn, vanaf welk type client de gebruiker zich ook aanmeldt. Deze informatie wordt het best opgeslagen op de server. Andere informatie kan variëren van client tot client. Zo kan het gepersonaliseerde adres bij de digitale televisie het thuisadres zijn, terwijl dat van de mobiele telefoon het werkadres is. Deze informatie wordt dan beter op het toestel opgeslagen. Merk wel op dat dit niet altijd mogelijk is en dat data in de client plots verwijderd kunnen worden. In dit geval moet de client deze informatie toch van de server halen. De gepersonaliseerde data kunnen ook gedistribueerd of gedupliceerd opgeslagen worden bij de client én de server. Wanneer de gepersonaliseerde data gedupliceerd zijn tussen de client en de server, zou een applicatie aanvullende mogelijkheden moeten hebben om de data te synchroniseren, wat natuurlijk een bepaalde kost meebrengt voor de ontwikkelaars.

2.4

De server zijde

De meeste van de huidige applicatie servers zijn ofwel gebaseerd op het Java 2 Platform, Enterprise Edition (J2EE), ofwel de Microsoft Product suit .Net. Wij zullen ons beperken tot applicatieservers gebaseerd op de J2EE standaarden. We zullen dit echter kort behandelen omdat dit minder interessant is in het kader van deze thesis en vele documentatie hierover reeds te vinden is. J2EE gebruikt een meerlagig gedistribueerd model (zoals te zien is in figuur 2.3). Dit model bevat een Client laag, Web laag, EJB laag een een EIS laag. De Client laag kan bestaan uit één of meerdere applicaties of browsers. Het J2EE Platform bestaat uit een Web Server en een EJB Server (die ook wel containers genoemd worden). De Enterprise Information System (EIS) laag bevat de bestaande applicaties, bestanden en databanken.

2.4 De server zijde

27

(secure) HTTP Xlet

Java/J2EE Applicatie Server Web laag Web Container

EJB laag EJB Container

JDBC

Servlet

EJB

Java Connectors

Servlet

EJB

Java Web Services

MIDlet

EJB EJB

EJB Servlet

JMS JavaMail

JSP

Browser

EIS laag

JNDI CORBA

Figuur 2.3: De gelaagde J2EE architectuur die verschillende types client ondersteunt J2EE is een uitbreiding van de Java 2 standaardeditie (J2SDK) met bijkomende bibliotheken voor het programmeren van serverapplicaties. Het is een platform-onafhankelijke, volledig ge¨ıntegreerde oplossing, die een open markt creëert, waarin elke leverancier kan leveren aan elke klant. Zo’n soort markt moedigt leveranciers aan om te innoveren en voorkomt dat klanten afhankelijk worden gemaakt van een eigen technologie (zoals bij Microsoft). Hiervan profiteren klanten door verbeterde producten en betere ondersteuning. Vele informatie over het J2EE platform is te vinden op de J2EE Website [23] en in de J2EE Tutorial [24]. Uitgebreide richtlijnen voor J2EE applicatie servers zijn te vinden in [20].

2.4.1

Java Servlets

Een Java servlet is hét communicatiemiddel tussen een client en een server. De servlet interpreteert de aanvragen van de client en zet die op zijn beurt om in aanvragen voor de EJB (Enterprise Java Bean) componenten. Wanneer de aanvragen uitgevoerd zijn, stuurt de servlet een antwoord terug naar de client. De EJB componenten, ook wel de enterprise beans genoemd, bevatten de bedrijfslogica van een applicatie. Een EJB container voorziet standaard diensten zoals transacties, beveiliging en resource management, zodat de ontwikkelaars zich volop kunnen concentreren op het implementeren van de bedrijfslogica zelf. Het J2EE platform legt de nadruk op herbruikbare componenten door het gebruik van enterprise beans. Applicaties kunnen deze componenenten gebruiken om verschillende types client te ondersteunen met weinig of geen impact op de bedrijfslogica van de applicatie. Hoewel de verschillende clients toegang krijgen tot verschillende servlets in de Web container, gebruiken ze toch indirect dezelfde EJB componenten om toegang te krijgen tot de bedrijfslogica en de persistente data in de databanken. Het resultaat is een echt toegankelijke onderneming (truly accessible enterprise): anytime, anywhere, from any device”. ”

2.4 De server zijde

28

Het plaatsen van een servlet tussen de client en de enterprise beans die de dienst representeren, is een goede keuze omwille van volgende redenen. • De server-zijde heeft geen informatie over het Java Runtime Environment (JRE) dat aan de client-zijde draait. Dus er is ook niet geweten als de client in staat is directe toegang te verkrijgen tot de enterprise beans. Elke versie van het JRE kan echter een eenvoudige XML parser draaien, wat de enige noodzaak is om diensten via servlets aan de clients aan te bieden (als verondersteld wordt dat het XML-formaat in combinatie met HTTP gebruikt wordt). • Clients achter firewalls zijn niet in staat om RMI-IIOP connecties te maken en kunnen dus geen onmiddellijke toegang verkrijgen tot de enterprise beans. De servlet is in staat elk formaat te ontvangen of te verzenden over het HTTP-protocol, dat wel door de firewall raakt. • De EJB’s blootstellen aan de buitenwereld is een veiligheidsrisico. De servlet acteert als controlepunt, waar beslist wordt welke enterprise bean functies beschikbaar mogen zijn voor de clients. • De servlet koppelt clients los van de EJB laag. De Web laag implementatie, die de servlets bevatten, kan aangepast worden naargelang er aanpassingen plaatsvinden in de entity beans, terwijl de originele communicatie met de clients dezelfde blijft. Deze mogelijkheid is minder belangrijk voor applets, die at runtime geladen worden, maar clients die vast ge¨ınstalleerd zijn op het toestel halen voordelen uit deze loskoppeling. • Afhankelijk van het type client kan een andere Java servlet ge¨ımplementeerd worden, die eventueel een andere functionaliteit van de applicatie biedt. Zo kan elke servlet rekening houden met de karakteristieken van het platform dat de servlet aanspreekt. De servlet voor digitale televisie zou zo in staat zijn figuren van hoge kwaliteit door te sturen naar de clients, terwijl de servlet voor mobiele telefoon eerder figuren van lage kwaliteit zal doorsturen. • Eén enkele servlet instantie behandelt alle aanvragen in aparte draden. • Servlets zijn schaalbaar en gemakkelijk te ontwikkelen.

2.4.2

Java Server Pages (JSP)

Java servlets zijn echter niet altijd de beste oplossing. Ze blijken minder van toepassing te zijn voor dynamische content-generatie voor browser clients. Hieronder volgen enkele nadelen van Java servlets. • Servlets, die acteren als HTML outputters, zijn vervelend om te schrijven en moeilijk te onderhouden. • Ze worden ontworpen door programmeurs, en programmeurs zijn over het algemeen slechte grafische ontwerpers. • De code van servlets kan moeilijk hergebruikt worden.

2.4 De server zijde

29

• In het dynamische Web is het meestal de data die veranderen en niet de structuur van elke pagina. Het hoofdprobleem van de servlettechnologie is een slechte scheiding van inhoud (de functionaliteit, de logica van de toepassing) en presentatie (de HTML-code, het visuele resultaat). De zogenaamde Java Server Pages (JSP) zijn hierop het antwoord. JSP kan gebruikt worden om elke vorm van content dynamisch te genereren (ook WML, DVB-HTML,. . . ), maar wordt meestal gebruikt om HTML markup te genereren. Net zoals servlets zijn ze ook een onderdeel van de Web laag. Enkele voordelen van Java Server Pages zijn: • ze zijn gemakkelijker te schrijven dan servlets • uigebreide programmeervaardigheden zijn niet noodzakelijk vereist • ze scheiden functie van vorm • ze ondersteunen codehergebruik Hieronder wordt een voorbeeld weergegeven:
De datum van vandaag is <%= new Date() %>
De normale HTML pagina definieert de structuur van het document en bevat een JSP-expressie die geëvalueerd wordt, wanneer de pagina opgevraagd wordt. Voor verdere informatie omtrent Java Server Pages verwijzen we de lezer naar [25].

2.4.3

Transactie Management

Het J2EE platform ondersteunt transacties op verschillende manieren. Ontwikkelaars kunnen transacties realiseren door gebruik te maken van de Java Transaction API of door te vertrouwen op een J2EE applicatie server om deze transacties automatisch te beheren. Bij het ontwikkelen van een client moeten ontwikkelaars er zich van bewust zijn dat transacties niet kunnen verspreid worden over verschillende HTTP-aanvragen. Elke HTTP-aanvraag heeft zijn eigen transactie context. Als een aanvraag verschillende operaties moet uitvoeren die transacties vereisen, worden deze operaties behandeld als één atomische unit. Bij het terugsturen van een HTTP-antwoord zijn ofwel alle operaties uitgevoerd, ofwel geen enkele. Als een client vervolgens een aanvraag ongedaan wenst te maken kan hij technisch gezien geen rollback 3 doen in een daarop volgende aanvraag, omdat deze een andere transactie context heeft. 3

Een rollback annuleert de voorgestelde aanpassingen in een databank, terwijl een commit deze bevestigt.

2.5 De communicatie tussen client en server

2.5

30

De communicatie tussen client en server

In figuur 2.3 werd de structuur getoond van een typische Java enterprise applicatie, waarbij verschillende apparaten in verbinding staan met een J2EE applicatie server. Er is gekozen om enkel de belangrijkste clients voor te stellen, waarvan de karakteristieken reeds besproken werden in sectie 2.2: een mobiele telefoon (een Java/J2ME client), een digitale televisie (Java/MHP client) en een Web browser (Java/JSP). We demonstreren nu eerst hoe de communicatie in zijn werk gaat tussen een Java/J2ME client (die een MIDlet draait) en de server. Bij de andere type clients verloopt de communicatie analoog. • Een MIDlet presenteert de gebruikersinterface op het mobiele toestel. Deze communiceert, normaalgezien via HTTP, met een Java servlet. Een veilig kanaal kan gebruikt worden, indien dit noodzakelijk is. • De servlet interpreteert aanvragen van de MIDlet en zet op zijn beurt de client-aanvragen om in aanvragen voor de EJB componenten. Wanneer deze voltooid zijn, stuurt de servlet een antwoord naar de MIDlet. • De servlet en EJB componenten mogen de J2EE API’s gebruiken om toegang te verkrijgen tot bedrijfsinformatie en -diensten. Ze mogen bijvoorbeeld gebruik maken van de JDBC API om toegang te krijgen tot relationele databanken, of van de JavaMail API om een e-mail te verzenden naar een gebruiker. Wanneer een gebruiker een dienst wil benutten op de server, moet de client gebruik maken van een protocol dat zowel door client als server verstaan wordt. Deze communicatie tussen client en server wordt nu besproken voor browser clients en Java clients.

2.5.1

Browser clients

Browsers connecteren met een applicatie server via het Web en gebruiken dus HTTP als transport protocol. Bij browser interfaces interageren gebruikers in het algemeen door gelinkte figuren of teksten te selecteren of door het invullen en doorsturen van formulieren. Browser clients vertalen dit in HTTP-aanvragen (requests) voor de Web server. Gebruikersaanvragen voor het ontvangen van data van op de server worden normaal omgezet naar HTTP GET aanvragen. De URL van de aanvraag bevat soms parameters die specifiëren welke data verkregen moeten worden. Een voorbeeld van dergelijke parameters is id=24513 in de link http://www.amazon.com/product?id=24513. Gebruikersaanvragen om data te updaten aan de server-zijde worden omgezet in HTTP POST aanvragen. Elk van deze aanvragen bevat een MIME veldje van het type application/x-www-form-urlencoded die de parameters bevat voor de update. De Servlet API voorziet een eenvoudige interface voor het behandelen van binnenkomende GET en POST aanvragen en voor het extraheren van de parameters, die met de aanvraag meegestuurd werden. Nadat een server een client-aanvraag behandeld heeft, moet ze een HTTP-antwoord (response) terugsturen. Het antwoord bevat meestal een HTML-document. De serverzijde kan gebruik maken van JSP (Java Server Pages) om de HTML-documenten te genereren.


2.5.2

31

Java clients

Java clients kunnen op drie manieren connectie maken met de J2EE applicatie server: als een Web client (die connecteert met de Web laag), als een EJB client (die connecteert met de EJB laag) of als een EIS client (die connecteert met de EIS laag). Web clients Net zoals browser clients connecteren Web clients over HTTP met de Web laag van een J2EE applicatie. Dit aspect van Web clients is bijzonder interessant op het internet, waar HTTPcommunicatie gewoonlijk de enige manier is, waarop een client de server kan bereiken. Voor de meeste applicaties is HTTP het beste communicatie protocol en is ze verkiesbaar boven andere communicatiemethoden zoals deze gebaseerd op sockets of datagrams. Dit omwille van onderstaande redenen: • Bijna alle apparaten ondersteunen HTTP-communicatie. Hierbij denken we voornamelijk aan handhelds, set-top boxen en web clients, die gebruik kunnen maken van HTTP-verbindingen. Socket- en datagram-gebaseerde communicatie wordt daarentegen niet ondersteund door alle handhelds. • HTTP is firewall vriendelijk. De meeste servers worden gescheiden van clients door een firewall, en HTTP is één van de weinige protocollen dat door de meeste firewalls doorgelaten wordt. • Java netwerk APIs maken HTTP programmeren gemakkelijker. Zo voorzien MIDP en MHP standaard ondersteuning voor HTTP 1.1 en bevatten ze API’s voor het genereren van GET/POST/HEAD aanvragen, het manipuleren van headers en het opstellen van berichten. Aan de server-zijde voorziet de Java servlet API een uitgebreid framework voor het verwerken van HTTP-aanvragen en het genereren van HTTP-antwoorden. • HTTP ondersteunt elk dataformaat. Dit formaat wordt in de HTTP-pakketjes meegestuurd als Content-Type. Enkele voorbeelden van formaten zijn: text/plain, text/html, image/jpg, image/gif, application/msword. Figuur 2.4 illustreert een HTTP-gebaseerd communicatiemechanisme tussen een Java client en een Java servlet. Wanneer een client communiceert met een Java servlet vinden de volgende gebeurtenissen plaats: • de client encodereert een applicatie aanvraag en pakt deze in in een HTTP-aanvraag, waarbij de Content-Type hoofding correct wordt ingesteld om te verzekeren dat tussenliggende gateways de aanvraag correct behandelen. Zo zal text/plain als content type passend zijn voor tekstuele aanvragen, terwijl application/octet-stream gebruikt zal worden voor binaire aanvragen. • de servlet ontvangt de HTTP-aanvraag en decodeert de applicatieaanvraag. De servlet voert het werk uit dat gespecifieerd werd in de applicatieaanvraag. • de servlet encodeert een applicatieantwoord en pakt het in een HTTP-antwoord in, waarbij de Content-Type en Content-Length hoofdingen juist worden ingesteld. Nu kan de Content-Type ook ingesteld worden als image/png voor het versturen van een png-figuur als antwoord.


32

HTTP aanvraag (request) POST /SmartTicket HTTP/1.1 Host: smartticket.java.sun.com Content-Type: application/octet-stream

applicatie aanvraag

MIDP client

Servlet HTTP antwoord (response) HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 512

applicatie antwoord

Figuur 2.4: HTTP-communicatie tussen een Java client en een Java servlet • de client ontvangt het HTTP-antwoord en decodeert het applicatieantwoord dat het omvat. Daarop kan de client één of meer objecten creëren en bewerkingen uitvoeren op deze lokale objecten. In tegenstelling tot browser clients kunnen Java clients berichten sturen en ontvangen in elk formaat. In de Java Smart Ticket applicatie kan een gebruiker bijvoorbeeld een lijst van films bekijken. Als de gebruiker een browser client had, zou de lijst in een HTML formaat gegoten worden voor ze doorgestuurd wordt naar de client. De Java client daarentegen kan deze lijst in verschillende formaten ontvangen. In de Smart Ticket applicatie wordt gebruik gemaakt van een binaire String. Binaire berichten kunnen eenvoudig gelezen en geschreven worden door gebruik te maken van de DataInputStream en DataOutputStream klassen in het java.io package. Verschillende methoden kunnen gebruikt worden om data te lezen en te schrijven, zoals bijvoorbeeld DataInputStream.readInt en DataOutputStream.writeInt voor het lezen en schrijven van Integers en DataInputStream.readUTF en DataOutputStream.writeUTF voor het lezen en schrijven van UTF-8 gecodeerde Strings. Een Java client zou ook een ander formaat kunnen kiezen, zoals bijvoorbeeld komma-gescheiden waarden: 1,Pinokio,2,Hans en Grietje,3,Finding Nemo,4,Lord of the Rings Of hij zou ook gebruik kunnen maken van sleutel-waarde paren: id=1,title="Pinokio" id=2,title="Hans en Grietje" id=3,title="Finding Nemo" id=4,title="Lord of the Rings" Een andere manier is om XML te gebruiken:


33

<movies> <movie> 1 Pinokio <movie> 2 Hans en Grietje <movie> 3 Finding Nemo <movie> 4 Lord of the Rings Hoewel het aantal mogelijkheden oneindig is, kunnen we alle berichtformaten op een denkbeeldige lijn plaatsen, waar binaire Strings zich aan de ene kant bevinden en XML documenten aan de andere kant. Om de algemene trade-offs van berichtformaten beter te verstaan helpt het om deze twee uitersten te beschouwen. Binaire berichten verbruiken weinig bandbreedte. Deze eigenschap is bijzonder aantrekkelijk in lage bandbreedte omgevingen (zoals bij draadloze en dial-up netwerken), waar elke byte telt. Daarom werd bij de Java Smart Ticket Demo voor mobiele telefoons het byte formaat verkozen voor het inpakken van informatie. HTTP-gebaseerde communicatie heeft wel een kost: er moet code geschreven worden voor het parsen en interpreteren van de berichten. Het schrijven van deze code, en vooral in geval van meerdere programmeerbare clients, kan tijdrovend zijn en niet foutvrij. Tevens moet de in- en uitpak code aan de client-zijde corresponderen met deze aan de server-zijde. Ze moeten beide op de hoogte zijn van het transportprotocol en zijn dus tightly coupled. Extensible Markup Languages (XML) berichten zijn het andere uiterste onder de berichtformaten. Terwijl het J2EE platform XML op vele manieren ondersteunt (in het bijzonder voor Web diensten), is dit niet standaard het geval bij vele client platformen (bijvoorbeeld MIDPapplicaties of MHP-applicaties). Ontwikkelaars zijn wel in de mogelijkheid XML-ondersteuning toe te voegen aan hun applicatie door additionele bibliotheken eraan toe te voegen. Voor XML-parsing en verwerking kunnen ontwikkelaars kiezen uit een groot aantal implementaties, inclusief deze die gebaseerd zijn op twee populaire verwerkingsmodellen, DOM en SAX. Rekening houdend met het beperkte geheugen en de beperkte rekenkracht van bepaalde apparaten (mobiele toestellen en digitale televisies) gaat de voorkeur uit naar SAX en gelijkaardige event-gebaseerde parsers, die seriële toegang hebben tot de XML-bestanden in plaats van random access toegang, zoals bij DOM het geval is. Verder zijn er ook XML-gebaseerde RPC bibliotheken beschikbaar, inclusief deze gebaseerd op de Simple Access Object Protocol (SOAP) specificatie. Verdere informatie over XML in Java applicaties vindt u in [26]. De mogelijkheid om berichten automatisch te parsen en te interpreteren reduceert de ontwikkelingstijd en helpt


34

bij het onderhouden en testen. Een ander voordeel van het gebruik van XML-berichten is dat het ondersteund wordt door alle types client, omdat XML een wereldwijd aanvaarde open standaard is. Zo kunnen bijvoorbeeld StarOffice Calc en Macromedia Flash clients beide bestellingsdata in het XML-formaat lezen van dezelfde JSP pagina en de data in hun respectivelijke interface presenteren. Ook kan XML gebruikt worden om berichten te encoderen van een grote variëteit aan clients. Een C++ client zou bijvoorbeeld een SOAP toolkit kunnen gebruiken voor het maken van remote procedure calls (RPC) tot een J2EE applicatie. Dit is natuurlijk een grote stap voorwaarts in het creëren van een platform-onafhankelijke applicatie. In het geval van handel op het Web zou het dus interessant zijn om alle producten in XMLbestanden op te slaan. Door deze in een gestandaardiseerde vorm op te slaan zorgen we niet alleen voor platform-onafhankelijkheid, maar besparen we de content providers ook heel wat werk. Zo hoeven ze de content maar één keer te creëren en kan deze content gebruikt worden voor e-commerce, t-commerce en m-commerce tegelijkertijd. Afhankelijk van de applicatie zullen meer of minder gegevens weergegeven worden. De veelzijdigheid van de XML-taal is één van zijn vele sterkten, en dus is zij bruikbaar in een brede waaier van applicaties die de nadruk leggen op structurering, uitwisseling en verwerken van informatie. In [27] wordt besproken hoe belangrijk de XML-standaard is voor het Multimedia Home Platform en digitale televisie in het algemeen. We eindigen dit XML-onderdeel met een opsomming van alle voordelen van het XML-formaat: • ze representeert de meeste soorten data ondubbelzinnig (wat niet het geval is bij HTML) • ze is gemakkelijk aanpasbaar en wordt door vele content management systemen gebruikt • ze laat validatie van documenten toe • ze is gemakkelijk leesbaar voor mensen en machines • het is een open standaard, beheerd door W3C • het is een formaat dat heel gemakkelijk kan gebruikt worden door zoekmachines. Bijvoorbeeld bij het zoeken van alle plaatsen waar een bepaald product verkocht wordt • de presentatie van de data kan vrij gekozen worden. Dezelfde content die in één formaat wordt opgeslagen, kan geleverd worden in verschillende vormen (HTML, WML, PDF,. . . ) • het wordt nog voor vele andere doeleinden gebruikt: CML (chemical structures), VoxML (voice), MathML (weergeven van wiskundige formules), DocBook (voor het schrijven van boeken of artikels),. . . EJB clients Wanneer gebruik gemaak wordt van Web clients moet code geschreven worden voor het vertalen van gebruikersopdrachten in HTTP-aanvragen, HTTP-aanvragen in applicatiegebeurtenissen, applicatieantwoorden in HTTP-antwoorden en HTTP-antwoorden in schermvernieuwingen. Als daarentegen EJB clients gebruikt worden moet geen dergelijke code geschreven worden, omdat


35

de clients direct connecteren met de EJB laag door gebruik te maken van Java Remote Method Invocation (RMI) oproepen. Spijtig genoeg is het connecteren als een EJB client niet altijd mogelijk. Eerst en vooral mogen enkel Applets en applicatie clients connecteren als EJB clients. MIDlets en Xlets kunnen geen connectie maken met de EJB laag, omdat RMI geen component is van MIDP en MHP. Ten tweede worden RMI oproepen ge¨ımplementeerd door gebruik te maken van IIOP, wat door de meeste firewalls geblokkeerd wordt. Wanneer dus een firewall een server en zijn clients scheidt, zoals dat bij het internet het geval is, is het gebruik van EJB clients geen optie. Binnen een bedrijfsnetwerk, waar zich geen firewalls tussen clients en server bevinden, kan wel een EJB client gebruikt worden. Clients zouden geauthenticeerd moeten worden om toegang te krijgen tot de EJB laag en daarbij is de client container verantwoordelijk voor het voorzien van dergelijke authenticatiemechanismes. EIS clients In het algemeen zouden Java clients niet rechtstreeks connectie mogen maken met de EIS laag van een J2EE applicatie. EIS clients eisen een krachtige interface, zoals de JDBC API, om data te manipuleren aan de remote resource. Wanneer deze interface misbruikt wordt (door een client met bugs of een kwaadwillig zelf gecreëerde client), kunnen de data misbruikt worden. Verder moeten niet-triviale EIS clients business logica implementeren. Omdat de logica gehecht is aan de client, is het moeilijker ze te delen onder verschillende types client. In bepaalde omstandigheden is het aanvaardbaar dat clients rechtstreeks toegang krijgen tot de EIS laag, zoals bijvoorbeeld bij administratie of management taken, waar de user interface klein is of niet bestaat en de taken eenvoudig en goed verstaanbaar zijn. Zo zou bijvoorbeeld een eenvoudig Java programma rechtstreeks onderhoud kunnen uitvoeren op databanken gedurende de nacht.

JAVA 2 MICRO EDITION (J2ME)

36

Hoofdstuk 3

Java 2 Micro Edition (J2ME) Bij de ontwikkeling van Java 1.2 werden binnen Sun Microsystems grote veranderingen doorgevoerd. Eerst en vooral werd Java 1.2 eenvoudigweg Java 2 genoemd (terwijl de JDK en JRE versies de 1.2 benaming bleven behouden). Maar belangrijker is echter dat het Java Platform opgesplitst werd in drie edities: • Java 2 Standard Edition (J2SE), voor de ontwikkeling van conventionele desktop applicaties. Naast het toevoegen van Swing werd ook een groot aantal nieuwe klassen toegevoegd om de ontwikkeling van applicaties nog meer te verbeteren dan reeds het geval was bij Java 1.1. • Java 2 Enterprise Edition (J2EE), die J2SE als deelverzameling heeft. Ze is geschikt voor het programmeren van bedrijfsapplicaties (enterprise applications) waarbij aan de server-zijde gebruik gemaakt wordt van Enterprise JavaBeans, servlets, JSP, CORBA en Extensible Markup Language (XML). Deze editie werd reeds kort besproken in hoofdstuk 2 van deze thesis. • Java 2 Micro Edition (J2ME), die een aangepaste deelverzameling is van J2SE voor ingebedde en handheld apparaten, die geen volledige J2SE implementatie kunnen ondersteunen. In dit hoofdstuk zullen we wat dieper ingaan op de laatst vernoemde editie: de Java 2 Micro Edition (J2ME). We zullen zien dat elk soort Java client, gaande van mobiele telefoons tot navigatiesystemen voor wagens, hiermee kan geprogrammeerd worden. In het vorig hoofdstuk vermeldden we reeds ontwerprichtlijnen voor Java clients, maar hier zullen we onderzoeken wat de verschillen en gelijkenissen zijn tussen de verschillende Java clients. Zo zullen ook applicatie clients, applet clients, MIDlet clients (voor mobiele telefoons) en Xlet clients (voor digitale televisie) binnen J2ME gesitueerd worden. Hoewel er enige overlapping is tussen de drie Java edities, is elke editie gericht op een ander type applicatie ontwerper. Het grote aantal beschikbare klassen bij J2EE en de complexiteit van hun gebruik staan sterk in contrast met de veel kleinere verzameling klassen, die een J2ME programmeur ter beschikking krijgt. Anderzijds moet een J2ME programmeur wel rekening houden met beperkingen op vlak van geheugen en bronnen. Door Java 2 op te splitsen in drie edities kan Java in drie verschillende richtingen evolueren, terwijl ze trouw blijft aan de oorspronkelijk Java kenmerken, waaronder de platform-onafhankelijkheid.

3.1 Configuraties

37

J2ME laat het dus toe Java applicaties te draaien op kleine, in geheugen beperkte toestellen. Het definieert geen nieuwe taal, maar het past de bestaande Java technologie aan voor handheld en ingebedde apparaten. Eigenlijk verwijdert J2ME bepaalde onderdelen van J2SE die niet toepasbaar zijn voor dergelijke toestellen, zoals de Abstract Windowing Toolkit (AWT) bijvoorbeeld. Sinds de publicatie van J2ME hebben reeds honderden bedrijven gekozen voor deze technologie, inclusief grote ondernemingen zoals Motorola, Nokia, Ericsson, Palm, Samsung, WindRiver, Sharp, Siemens, Sympian en RIM. Dit is niet verwonderlijk, daar J2ME een complete verzameling oplossingen biedt voor het creëren van state-of-the-art netwerk applicaties voor kleine toestellen. Een toegevoegde waarde is dat de richting, waarin J2ME evolueert, niet in het geheim beslist wordt, maar dat ze open besproken wordt via het Java Community Process (JCP). We vervolgen met een beschrijving van de basiscomponenten van J2ME: configuraties en profielen.

3.1

Configuraties

Een configuratie definieert de basis J2ME runtime omgeving. Deze omgeving includeert enerzijds de virtuele machine (VM), die beperkter kan zijn dan de Java Virtual Machine (JVM) die gebruikt wordt door J2SE, en anderzijds een verzameling basisklassen, die grotendeels afgeleid zijn van J2SE. Men kan een configuratie beschouwen als een vertikale verzameling van API’s, die de basisfunctionaliteit voorzien voor een bepaalde groep toestellen, die gelijkaardige karakteristieken vertonen zoals geheugenverbruik en netwerkconnectiviteit. Later zullen we zien dat profielen hierop gebouwd zullen worden. In de huidige situatie zijn er twee configuraties gedefinieerd: de Connected Device Configuration (CDC) en de Connected Limited Device Configuration (CLDC). Beide configuraties zijn gericht op toestellen met netwerk connectiviteit en zijn onafhankelijk van het type verbinding (snelle bedrade of trage draadloze verbinding). Naarmate J2ME zich verder ontwikkelt, zullen in de toekomst nog andere configuraties gedefinieerd worden. Figuur 3.1 toont op een eenvoudige manier de relatie tussen CDC en CLDC. Het toont ook hun relatie tot de volledige J2SE API. In figuur 3.2 wordt de onderverdeling van Java 2 in verschillende edities ge¨ıllustreerd. Ook worden de vorige configuraties met hun corresponderende toestellen weergegeven.

J2SE CDC CLDC

Figuur 3.1: De relatie tussen J2SE, CLDC en CDC

3.1 Configuraties

38

servers

desktops laptops …

set-top boxen mobiele telefoons communicators pagers navigatiesystemen PDA’s … … CDC

J2EE

J2SE

CLDC

J2ME Java Platform

JVM

KVM

Figuur 3.2: De verschillende edities binnen Java 2

3.1.1

Connected Limited Device Configuration (CLDC)

CLDC heeft als doelgroep de kleinere toestellen zoals mobiele telefoons, personal digital assistants (PDA’s), interactieve pagers en kleine betaalsystemen. Deze groep van toestellen heeft belangrijke beperkingen op vlak van rekenkracht, geheugen en bandbreedte. Deze beperkingen be¨ınvloeden rechtstreeks alle ondersteunde Java applicaties. De karakteristieken van de toestellen, die deze configuratie gebruiken, zijn: • minimaal 160 kB geheugen beschikbaar voor het Java Platform • gelimiteerde rekenkracht • stroomvoorziening meestal door batterijen • minimaal 128 kB ROM geheugen voor de opslag van de VM en de klasse-bibliotheken • minimaal 32 kB RAM geheugen dat gebruikt wordt voor het alloceren van run-time geheugen • geconnecteerd met het netwerk (dikwijls een draadloze inconsistente connectie met gelimiteerde bandbreedte) • user interfaces met gevarieerde graden van geavanceerdheid, soms zonder een interface CLDC definieert een aantal vereisten voor de Java run-time omgeving. De eerste vereiste is dat de Java taal en VM volledig ondersteund worden op enkele verschillen na, die te vinden zijn in [29]. De tweede vereiste is dat de overgeërfde klassen uit J2SE deelverzamelingen zijn van de J2SE 1.3 klassen. Er kunnen methoden weggelaten worden, maar er kunnen geen nieuwe publieke methoden of data toegevoegd worden. Op deze manier wordt upward-compatibiliteit gegarandeerd. De derde vereiste is dat de (nieuwe) klassen, die door CLDC gedefinieerd worden, zich in het javax.microedition package bevinden, wat het gemakkelijker maakt om deze te identificeren. Een laatste vereiste is een minimale ondersteuning voor internationalisatie (i18n).

3.2 Profielen

39

Bij CLDC kan gebruik gemaakt worden van Sun’s K(ilobyte) Virtual Machine (KVM) die als referentie ontworpen is voor CLDC. Verkopers kunnen echter ook hun eigen virtuele machine creëren.

3.1.2

Connected Device Configuration(CDC)

CDC voorziet een verzameling basisbibliotheken en een Java virtuele machine, die geschikt is voor krachtigere toestellen die (eventueel onderbroken) geconnecteerd zijn met het netwerk, zoals set-top boxen, home-applicaties, organizers en navigatiesystemen voor wagens. De karakteristieken van de toestellen, die deze configuratie gebruiken zijn: • ze zijn voorzien van een 32-bit processor, terwijl dit bij CLDC ook een 16-bit processor kon zijn • minstens 2MB totaal geheugen beschikbaar voor het Java Platform • ze moeten de volledige functionaliteit hebben van de Java 2 virtuele machine specificatie • geconnecteerd met het netwerk (dikwijls een draadloze inconsistente connectie met gelimiteerde bandbreedte) • user interfaces met gevarieerde graden van geavanceerdheid, soms zonder een interface De grens tussen CDC en CLDC is niet duidelijk, omdat bepaalde toestellen, die normaal bij CLDC behoren (zoals geavanceerde mobiele telefoons en PDA’s) toch kunnen voldoen aan de voorwaarden van CDC. In dit geval zal de fabrikant van het toestel moeten bepalen welke configuratie ondersteund wordt. Merk op dat CLDC een deelverzameling is van CDC: CDC includeert dus alle klassen die gedefinieerd worden door CLDC. Bovendien is CDC voorzien van veel meer basis J2SE klassen dan CLDC, waardoor CDC een meer vertrouwelijke en comfortabele omgeving biedt voor ervaren Java programmeurs. Programmeren voor CLDC zal voor hen dus een grotere uitdaging zijn. Merk op dat applicaties, die geschreven zijn door gebruik te maken van de CLDC API’s, upward-compatibel zijn met CDC. Waarschijnlijk is het grootste verschil tussen CDC en CLDC dat CDC een volledige Java virtuele machine nodig heeft die compatibel is met deze in J2SE. Met andere woorden, de CDC VM moet alle geavanceerde mogelijkheden van een J2SE VM ondersteunen, inclusief interfaces voor lowlevel debugging en native programming. Hiervoor heeft Sun een nieuwe Java VM uitgebracht, de Compact VM (CVM), die meer geschikt en efficiënter is dan de standaard VM.

3.2

Profielen

Een profiel breidt een configuratie uit en voegt domein specifieke klassen toe. Profielen voorzien dus klassen, die gericht zijn op specifiek gebruik van een bepaald type toestel. Deze klassen bieden een functionaliteit aan, die niet aanwezig is in de basis configuratie. Ze definiëren het life-cycle model, de user interface en toegang tot diensten, die voorzien worden door een bepaald type toestellen.

3.2 Profielen

40

Profielen hebben echter ook een nadeel: terwijl ze enerzijds een belangrijke en noodzakelijke functionaliteit voorzien, zal anderzijds niet elk toestel een bepaald profiel ondersteunen. In Japan bijvoorbeeld heeft NTT DoCoMo een aantal Java mobiele toestellen uitgebracht, die gebaseerd zijn op CLDC maar met een eigen aangepast profiel. Applicaties, die geschreven zijn voor deze toestellen, zullen niet werken op mobiele toestellen, die het Mobile Information Device Profile (dat we later zullen bespreken) ondersteunen. Een aantal profielen zijn reeds gedefinieerd of zijn nog in ontwikkeling. We bespreken nu voor beide configuraties de mogelijke profielen. Dit wordt eenvoudig voorgesteld in figuur 3.3.

PP PBP

RMI P

…

MIDP

PDAP

FP CDC

CLDC

Figuur 3.3: De verschillende profielen binnen J2ME

3.2.1

Profielen voor CLDC

Mobile Information Device Profile (MIDP) Het eerste profiel dat vrijgegeven werd, was het Mobile Information Device Profile, voor het ontwikkelen van applicaties voor mobiele telefoons en interactieve pagers met kleine schermen, een draadloze connectie en een beperkt geheugen. MIDP includeert een low-level UI API en een high-level UI API. De low-level API laat de ontwikkelaar toe volledige toegang te krijgen tot het scherm van het toestel, maar voorziet geen standaard user interface componenten. De applicatie moet dus zelf expliciet buttons tekenen en andere componenten. De high-level API definieert eenvoudige user interface componenten, maar voorziet geen directe toegang tot het scherm. De componenten zijn abstract omwille van verschillen in schermgrootte en inputmethodes tussen de toetellen. De MIDP implementatie zal dan deze abstracte componenten invullen op basis van het toestel. Information Module Profile (IMP) Een tweede profiel dat reeds gebruikt wordt is het Information Module Profile voor headless devices zoals verkoopapparatuur, industriële toestellen en beveiligingssystemen.

3.2 Profielen

41

KJava KJava bevat een Sun-specifieke API, die draait op het Palm OS (Operating System). Deze API heeft veel gemeen met de J2SE Abstract Windowing Toolkit (AWT) API. KJava is een Sun API, die eigenlijk niet bedoeld was als een compleet ondersteund profiel, maar eerder als een demonstratie van hoe een profiel kon werken met CLDC. Ondanks dit feit wordt het KJava profiel wereldwijd gebruikt door ontwerpers. Omdat dit geen officieel profiel is, zijn de GUI klassen van het package com.sun.kjava geen onderdeel van het Connected Limited Device Configuration. Officiële GUI klassen voor J2ME kunnen gevonden worden in de eerder vermelde J2ME profielen. Personal Digital Assistant Profile (PDAP) Een ander, op CLDC gebaseerd profiel, is het Personal Digital Assistant Profile (PDAP) dat nog in ontwikkeling is. Het breidt MIDP uit met additionele klassen en mogelijkheden voor krachtigere handheld toestellen.

3.2.2

Profielen voor CDC

Foundation Profile (FP) CDC heeft een aantal klassen nodig om de virtuele machine te draaien, maar dit zijn niet alle standaard Java klassen. Het Foundation Profile (FP) breidt CDC uit met toegevoegde J2SE klassen. Een CDC/Foundation applicatie zal onder J2SE en J2EE draaien, maar het omgekeerde is niet verzekerd. Dit profiel acteert als een basis om andere profielen op te bouwen. Profielen kunnen namelijk op elkaar gebouwd zijn, zoals het Personal Profile dat een extensie is van het Foundation Profile. Er wordt verwacht dat meerdere profielen hierop gebaseerd zullen worden gedurende de evolutie van J2ME. Omwille van zijn foundation-functie worden enkel API’s voorzien voor basis applicatie ondersteuning en geen UI API’s, omdat niet alle profielen, die zich hierop willen baseren, een user interface nodig hebben. Personal Basis Profile (PBP) Het Personal Basis Profile (BPB) breidt het Foundation Profile uit met lichtgewicht (lightweight) user interfase klassen (afgeleid van AWT), het Xlet applicatiemodel en het traditioneel applicatiemodel. Door het excluderen van de zwaargewicht (heavyweight) AWT componenten gebruikt ze ook minder geheugen op het toestel, maar ondersteunt ze daarentegen wel geen applets. Dit wordt ge¨ıllustreerd in figuur 3.4. Het Personal Basis Profile is bedoeld voor netwerk-geconnecteerde toestellen, die een normale grafische user interface hebben. Het PBP is bruikbaar voor de interactieve televisie markt, omdat het de noodzakelijke API’s bevat voor de ontwikkeling van applicaties op het MHP-Platform. Het Personal Basis Profile is ook compatibel met andere grote specificaties voor gebruikselektronica zoals Home Audio-Video interoperability (HAVi) en OpenCable Application Profile (OCAP)

3.2 Profielen

42

J2SE packages

CDC

FP

PBP

microedition package

AWT Java core packages

javax packages

Swing

Figuur 3.4: De klassenstructuur bij het Personal Basis Profile specificatie voor iTV diensten en MHP gebaseerde applicaties, en het DTV Applications Software Environment (DASE), een geavanceerde televisiestandaard die middleware definieert die toelaat interactieve applicaties te draaien op een gemeenschappelijke ontvanger. Een belangrijke eigenschap van het Personal Basis Profile is dat het Xlets ondersteunt. Xlets kunnen mogelijks een belangrijkere rol spelen in J2ME dan de rol van een applet in J2SE. Het downloaden van third-party Xlets voorziet een manier voor een PDA om dynamisch zijn functionaliteit uit te breiden. Een Xlet kan zelfs diensten aanbieden aan andere Xlets via InterXlet communicatie, waardoor het gemakkelijk wordt om client-server applicaties te maken, die bestaan uit meerdere Xlets met een fijne modulariteit. Eén van de verschillen tussen iTV in J2ME en MIDP in J2ME is het gebruik van PersonalJava klassen zoals AWT voor het genereren van de grafische user interface. In het kader van deze thesis gaan we wat dieper in op het Multimedia Home Platform en zijn specificaties. DVB-MHP (of gewoonweg MHP) is een open standaard om een universeel multimedia home platform te creëren voor interactieve Digitale Televisie (iDTV) diensten. MHP werd gerealiseerd door het Digital Video Broadcasting Project (DVB), een Europees-gebaseerd consortium voor broadcast companiën, set-top box fabricanten, regelgevende instellingen,. . . In juli 2000 werd de eerste MHP specificatie (MHP 1.0) formeel geaccepteerd door het European Telecommunications Standard Institute (ETSI). MHP definieert een generische interface tussen interactieve digitale applicaties en de set-top boxen waarop deze applicaties draaien. Deze interface is een Application Programming Interface (API) die gebaseerd is op java. Ze koppelt de applicaties en zijn providers los van de specifieke software en hardware details van de verschillende set-top boxen. Op die manier creëert MHP een zogenaamde horizontale markt, waar er concurrentie mogelijk is tussen content providers, netwerk operatoren, hardware ontwikkelaars,. . . Zo zal de MHP-standaard zorgen voor een lagere ontwikkelingskost van applicaties. Oorspronkelijk was MHP gebaseerd op een deelverzameling van PersonalJava 1.2 [28]. Verschillende onderdelen werden verwijderd om plaats te besparen of omdat ze niet functioneel waren voor digitale televisie. Ook werden bepaalde delen toegevoegd, zoals additionele API’s voor

3.2 Profielen

43

STB-specifieke functies. Daarnaast werden ook bepaalde delen veranderd, omdat het computergecentreerd model moest aangepast worden aan het tv-gecentreerd model. Met de komst van J2ME werd PersonalJava echter vervangen door de combinatie van CLDC met het Personal Profile (dat het volgende profiel is dat besproken wordt). Daarom moest voor toekomstige MHP specificaties een oplossing gevonden worden. Omwille van verschillende redenen werd gekozen om MHP 1.1.2 te baseren op het J2ME Personal Basis Profile. Eerst en vooral is PBP ontworpen om upwards compatibel te zijn met de DVB deelverzameling van PersonalJava en werd PBB bovendien ontwikkeld door vele MHP medewerkers. Ook is PBP ervoor ontworpen om beter te zijn dan PersonalJava. Enerzijds zijn er voordelen voor de MHP ontwikkelaars, die op deze manier eenvoudiger kunnen onderhandelen over licenties (zonder deelverzamelingen van specificaties te moeten beschouwen), een mooiere integratie hebben tussen de klassieke Java bibliotheken en de MHP implementatie, en typisch een hogere performantie verkrijgen op dezelfde hardware. Anderzijds zijn er ook voordelen voor de applicatieontwikkelaars. Zo krijgen zij extra mogelijkheden, zoals het gebruik van de Collections API, zwakke referenties,. . . Personal Profile (PP) Om Web gebaseerde applets te ondersteunen werd het Personal Basis Profile uitgebreid tot het Personal Profile door het toevoegen van packages, die een geavanceerde grafische user interface ondersteunen. De zwaargewicht AWT componenten, die bij het Personal Basis Profile uitgesloten werden, worden hier wel ge¨ıncludeerd. Het Personal Profile is een herdefiniëring van PersonalJava, en is daarom backward-compatibel met PersonalJava 1.1 en 1.2 applicaties. Met andere woorden, het voorziet de functionaliteit van de PersonalJava omgeving in een next-generation J2ME profiel. De PersonalJava technologie zal dus getransformeerd worden in de som van de Connected Device Configuration (CDC) en het Personal Profile. Dit wordt weergegeven in figuur 3.5. Het Personal Profile is een uitbreiding van het Personal Basis Profile. Zo zullen applicaties, die op dit laatste profiel gebaseerd zijn, upward-compatibel zijn met het Personal Profile. Een Xlet, die geschreven is voor het Personal Basis Profile, kan dus ook gedraaid worden op het Personal Profile. Merk op dat de meeste Personal Profile applicaties en applets uitgevoerd kunnen worden in een J2SE omgeving, maar Xlets, die het javax.microedition package gebruiken, kunnen dit niet. Het Personal Profile kan gebruikt worden voor het creëren van een grote variëteit aan applicaties voor PDA’s, telematica, iTV, lotterij terminals, medische toestellen, home applicaties die huishoudelijke diensten realiseren (centrale verwarming, entertainment, beveiliging),. . . RMI Profile Het RMI Profile is een profiel dat RMI (Remote Method Invocation) ondersteuning toevoegt aan CDC.

niet-grafische bibliotheken

basis klassen

JVM

Personal Profile

PAWT+

44

Connected Device Configuration (CDC)

Huidige PersonalJava applicatieomgeving

3.3 De verschillende applicatiemodellen binnen J2ME

Figuur 3.5: PersonalJava binnen de context van de J2ME architectuur

3.3

De verschillende applicatiemodellen binnen J2ME

Het beheer van een applicatie (hoe ze gestart of gestopt wordt, wanneer ze toegang verkrijgt tot systeembronnen, hoe het zijn initialisatieparameters ontdekt,. . . ) is verdeeld over het besturingssysteem (of andere software op systeem niveau) en de applicatie zelf. Het applicatiemodel definieert hoe een applicatie beheerd wordt en hoe managementverantwoordelijkheden verdeeld worden onder de applicatie en het onderliggend systeem. Het Java 2 Platform, Micro Edition (J2ME) ondersteunt in zijn huidige situatie vier verschillende applicatiemodellen. Hieronder wordt elk van hen beschreven. Voor meer gedetailleerde informatie hierover verwijzen we naar [30].

3.3.1

Het traditionele applicatie model

Het eenvoudigste applicatiemodel is het traditionele applicatiemodel, zoals dat beschreven wordt in hoofdstuk 12 van The Java Language Specification [32]. Het startpunt van de applicatie is een statische methode main() genaamd. Dit wordt weergegeven in onderstaand voorbeeld. public class ApplicatieVoorbeeld{ public static void main(String[] args){ // De applicatie start hier } } De klasse die deze methode definieert, wordt meestal de hoofdklasse genoemd. Om de applicatie te starten laadt de Java Virtual Machine de hoofdklasse in en roept ze zijn main() methode


45

op. Het uitvoeren van een applictie kan op twee manieren beëindigd worden. Ofwel beëindigt ze zichzelf door System.exit() te roepen (als de security manager dit toelaat), ofwel wordt ze automatisch beëindigd na het uitvoeren van alle niet-daemon draden (inclusief degene die de applicatie gestart heeft). Zo kan de volgende applicatie enkel gestopt worden door het besturingssysteem, omdat het een draad bevat die nooit beëindigd wordt. public class Voorbeeld extends Thread { public void run(){ while(true){ try { sleep(1000); } catch(InterruptedException e){} } } public static void main(String[] args){ Voorbeeld vb = new Voorbeeld(); vb.run(); } } Hoewel het besturingssysteem de applicatie kan beëindigen zonder dat dit opgemerkt wordt, heeft de applicatie de complete controle over zijn levenscyclus: wanneer ze eindigt en wanneer ze systeembronnen krijgt of vrijgeeft. De applicatie is dus een onbeheerde applicatie, het besturingssysteem treedt enkel op bij zijn activatie. Als het besturingssysteem plots de applicatie beëindigt, heeft de applicatie de kans niet om zijn toestand op te slaan of de systeembronnen vrij te geven waarover hij beschikte. Voor vele doeleinden is het traditioneel applicatiemodel een goede keuze. De meeste interactieve J2SE en PersonalJava applicaties moeten namelijk niet beheerd worden, en worden enkel beëindigd op het commando van de gebruiker. Op deze manier kan de gebruiker applicatievensters minimaliseren of verplaatsen om toegang te krijgen tot andere applicaties, zonder daarbij de huidige applicatie af te moeten sluiten of te pauzeren om systeembronnen vrij te geven. Op het J2ME platform wordt het traditionele applicatie model ondersteund door beide configuraties (CDC en CLDC), maar bepaalde individuele profielen ondersteunen het niet. Zo wordt het wel ondersteund door het Personal Basis Profile en het Personal Profile, maar niet door het Mobile Information Device Profile en het Personal Digital Assistant Profile.

3.3.2

Het Applet model

Een applet is een ingebedde applicatie, die draait onder de controle van een web browser. De applet heeft een nauwe band met de web pagina waarin ze vervat zit, omdat deze het gebied voorziet waarin de applet weergegeven kan worden. Eigenlijk heeft de applet zijn user interface niet volledig onder controle. De gebruiker kan zich in de browser voortbewegen van pagina tot pagina zonder hiervoor toelating te vragen aan de applet. Het is zinvol de applet te laten pauzeren of zelfs te vernietigen wanneer de gebruiker naar een andere pagina gaat, en deze


46

verder te zetten of te herstarten wanneer de gebruiker terugkeert naar de originele pagina. In tegenstelling tot traditionele applicaties zijn applets beheerde applicties, omdat hun levenscyclus onder de controle valt van de browser. Het Applet model binnen J2ME is natuurlijk niet nieuw, en werd reeds ondersteund bij eerste publieke vrijgaves van Java. Op het J2ME platform wordt applet ondersteuning enkel teruggevonden in het Personal Profile. De levenscyclus van een applet De hoofdklasse in een applet is een extensie van de java.applet.Applet klasse, die zelf een extensie is van de java.awt.Panel klasse. Naast het definiëren van het weergavegebied van een applet, definieert de hoofdklasse vier levenscyclus notificatiemethoden: init(), start(), stop() en destroy(). De levenscyclus van een applet (zie figuur 3.6) heeft vier toestanden: • geladen (loaded ): een applet instantie is geconstrueerd, maar de initialisatie heeft nog niet plaatsgevonden • gestopt (stopped ): de applet is ge¨ınitialiseerd, maar is inactief • gestart (started ): de applet is actief • vernietigd (destroyed ): de applet is beëindigd en de applet instantie is klaar om verwijderd te worden door de garbage collector

Loaded

init()

destroy()

destroy()

Stopped

stop() start()

Destroyed

destroy()

Started

Figuur 3.6: Lifecycle van een applet Een applet wordt gecreëerd, wanneer de web browser een pagina met de gepaste tags inlaadt en weergeeft. Ontwikkelaars van HTML pagina’s gebruiken de applet tag, zoals in onderstaand voorbeeld.


47

Er zijn andere manieren om een applet te laden, maar het effect is hetzelfde: de browser downloadt de hoofdklasse van de applet en de verplichte publieke constructor zonder argumenten (public BasisApplet()) creëert een instantie van de klasse. De initiële toestand van een applet is loaded. In het algemeen zou de applet geen enkele initialisatie mogen verwezelijken in zijn constructor. De reden daarvoor is dat zijn operating context dan nog niet ingesteld is. Deze operating context bevat belangrijke informatie zoals de applet’s parent container en initialisatieparameters. Wanneer de context ingesteld is, verandert de browser de applet’s toestand naar stopped en wordt de init() methode opgeroepen. Deze methode wordt slechts eenmaal opgeroepen gedurende zijn hele levenscyclus, voordat één van de andere notificatiemethoden opgeroepen wordt. Eenmaal de applet ge¨ınitialiseerd is, kan ze geactiveerd worden. Activatie (een verandering van de stopped toestand naar de started toestand) vindt plaats wanneer de browser de web pagina weergeeft die de applet bevat. Bij het activeren wordt de start() methode opgeroepen. De applet kan deze mehtode gebruiken om verdere initialisatie uit te voeren, zoals het creëren van achtergrond draden en andere bron-intensieve activiteiten. Het tegenovergestelde van activatie is desactivatie en vindt plaats, wanneer de toestand van de applet terug verandert van started naar stopped. Deze transitie gebeurt gewoonlijk, wanneer de browser stopt met het weergeven van de pagina die de applet bevat, bijvoorbeeld als een gebruiker de terug-knop van de browser indrukt. Desactivatie roept de stop() methode op. De applet geeft dan normaal alle bronnen vrij die verkregen werden gedurende de start() methode. Merk op dat het vrijgeven van deze bronnen vrijwillig gebeurt door de applicatie en dat het systeem de applicatie niet dwingt om dit te doen. Wanneer de applet gestopt is, kan de browser de applet vernietigen om zo de resterende toegewezen bronnen vrij te geven. Dit kan ofwel onmiddellijk na het stoppen van de applet, ofwel na het verlopen van een lang tijdsinterval sinds zijn desactivatie. Het vernietigen van de applet roept zijn destroy() methode op, die de applet nog een laatste kans heeft om iets te doen, terwijl zijn operating context nog geldig is. De code van een basis applet ziet er als volgt uit: public class BasisApplet extends java.applet.Applet { public BasicApplet(){ // constructor, Doe niet veel hier! } public void init(){ // De applet context is klaar // Voer alle eenmalige initialisaties hier uit! } public void start(){ // De applet wordt weergegeven }


48

public void stop(){ // De applet wordt verborgen } public void destroy(){ // Geef alle bronnen vrij! } } De applet context Naast het definiëren van notificatiemethoden definieert de java.applet.Applet klasse ook methoden, die de applet laten interageren met zijn operating context, de omgeving waarin hij draait. De getParameter() methode bijvoorbeeld, geeft de parameterwaarden van de applet terug. Enkele methoden worden gedeclareerd door de java.applet.AppletContext interface, dit is een instantie die teruggegeven wordt door de getAppletContext() methode. De applet context is belangrijk omwille van twee redenen. Eerst en vooral laat het een applet toe bronnen te verkrijgen van een web browser, zoals initialisatieparameters, figuren en audio clips. Ten tweede is de applet daardoor in staat de web browser te controleren, terwijl die uitgevoerd wordt. Deze controle is beperkt tot de volgende mogelijkheden: • het herschalen van de applet (de browser kan dit echter weigeren) • het spelen van een audio clip • het weergeven van een bericht in de browser’s status bar • het openen van een nieuw browser scherm met een gespecifieerde URL • het vervangen van de huidige web pagina door een nieuwe Merk op dat, in tegenstelling tot andere soorten applicaties, een applet geen manier heeft om zijn levenscyclus direct te be¨ınvloeden. Om zichzelf te desactiveren kan een applet wel de huidige web pagina vervangen door een nieuwe. Voor het ontwikkelen van applicatie clients en applet clients verwijzen we u naar The Java Tutorial [31].

3.3.3

Het MIDlet model

Een MIDlet is een Mobile Information Device Profile (MIDP) applicatie. Zoals een applet is een MIDlet een beheerde applicatie. In plaats van beheerd te worden door een web browser wordt het daarentegen beheerd door speciaal voorziene Application Management Software (AMS) die ingebouwd is in het toestel (mobiele telefoon, interactieve pager,. . . ). Extern beheer van de applicatie is hier zinvol, omdat deze op om het even welk ogenblik onderbroken moet kunnen worden door gebeurtenissen van buitenaf. Zo mag bijvoorbeeld een geactiveerde applicatie niet verhinderen dat een gebruiker een binnenkomend gesprek kan beantwoorden. Het MIDlet model wordt ook ondersteund door het Personal Digital Assistant Profile (PDAP), dat het model uitbreidt om applicaties te ondersteunen die PDAlets genoemd worden.


49

De MIDlet levenscyclus De hoofdklasse van een MIDlet (zie figuur 3.7) is een extensie van de javax.microedition.midlet.MIDlet klasse en definieert drie levenscyclus notificatiemethoden: startApp(), pauseApp() en destroyApp(). Er zijn drie mogelijke toestanden in een MIDlet’s levenscyclus: • gepauseerd (paused ): de MIDlet instantie is geconstrueerd maar onactief • actief (active): de MIDlet is actief • vernietigd (destroyed ): de MIDlet is beëindigd en klaar om verwijderd te worden door de garbage collector

Paused

pauseApp() destroyApp()

Destroyed

startApp()

destroyApp()

Active

Figuur 3.7: Lifecycle van een MIDlet Merk op dat er geen equivalent is voor een applet’s loaded toestand, omdat er geen initialisatie methode is. Een MIDlet initialiseert zichzelf de eerste keer de startApp() methode opgeroepen wordt. MIDlets worden gecreëerd door de AMS, gewoonlijk op verzoek van een gebruikersaanvraag. Zo kan de AMS alle MIDlets, die ge¨ınstalleerd zijn op het systeem, in een lijst weergeven en de gebruiker er één laten kiezen. Een MIDlet’s initiële toestand is paused. Net zoals bij een applet het geval is zou een MIDlet weinig of geen initialisatiewerk mogen uitvoeren in zijn constructor, omdat zijn operating context dan nog niet ingesteld is. Op een bepaald ogenblik na zijn constructie, activeert de AMS de MIDlet en roept ze de startApp() methode op. Na de nodige initialisatie uitgevoerd te hebben creëert startApp() de user interface en geeft die ook weer. Na het uitvoeren van startApp() verandert de MIDlet’s toestand van paused naar active. Als de MIDlet niet ge¨ınitialiseerd kan worden om één of


50

andere reden, geeft ze een javax.microedition.midlet.MIDletStateChangeException waardoor ze onmiddellijk overgaat naar de destroyed toestand. Desactivatie gebeurt bij elke transitie van active naar paused. De MIDlet wordt dan niet vernietigd, maar moet zoveel mogelijk systeembronnen vrijgeven. Als de desactivatie gestart wordt door de AMS, wordt de MIDlet’s pauseApp() methode opgeroepen. Als de MIDlet echter zichzelf desactiveert door gebruik te maken van zijn operating context, wordt pauseApp() niet opgeroepen. Vernietiging vindt plaats, wanneer de MIDlet’s toestand verandert van active of paused naar destroyed. Als de vernietiging ge¨ınitialiseerd wordt door de AMS, wordt de MIDlet’s destroyApp() methode opgeroepen. Een boolean parameter die meegegeven wordt aan de methode, bepaalt of de vernietiging onvoorwaardelijk is (het moet gebeuren) of optioneel. De MIDlet kan optionele vernietiging weigeren door een MIDletStateChangeException terug te geven. Als de MIDlet zichzelf vernietigt, wordt destroyApp() niet opgeroepen. De code voor een basis MIDlet ziet er als volgt uit: import javax.microedition.midlet.*; public class BasisMIDlet extends MIDlet { public BasisMIDlet(){ // constructor, doe niet veel hier! } protected void destroyApp(boolean unconditional) throws MIDletStateChangeException { // Opgeroepen wanneer het systeem de MIDlet vernietigd } protected void pauseApp(){ // Opgeroepen wanneer het systeem de MIDlet pauzeert } protected void startApp() throws MIDletStateChangeException { // Opgeroepen wanneer het systeem de MIDlet activeert } } De MIDlet Context De javax.microedition.midlet.MIDlet klasse definieert ook methoden, die een MIDlet laten interageren met zijn operating context. getAppProperty() geeft de initialisatieparameters terug, resumeRequest() vraagt de AMS om de MIDlet te reactiveren, notifyPaused() brengt de MIDlet in de paused toestand en notifyDestroyed() brengt de MIDlet in de destroyed toestand. De MIDlet initialisatieparameters zijn naam-waarde paren, die zich in de MIDlet’s applicatie descriptor of het manifest bevinden. De applicatie descriptor is een afzonderlijke tekst file, die belangrijke informatie bevat over een verzameling MIDlets die samen verpakt zijn in één enkele JAR file (een MIDlet suite).


51

Het manifest is het standaard JAR manifest, dat ingepakt zit in de MIDlet suite. Wanneer getAppProperty() opgeroepen wordt, wordt eerst de applicatie descriptor gezocht en daarna het manifest. We merken op dat MIDP 2.0 het concept vertrouwde suites invoert, waarbij getAppProperty() enkel het manifest doorzoekt. De overige methoden be¨ınvloeden rechtstreeks de MIDlet’s levenscyclus. Een gepauzeerde MIDlet roept resumeRequest() op om gereactiveerd te worden. Een actieve MIDlet roept notifyPaused() op om gedesactiveerd te worden. Een gepauseerde of actieve MIDlet roept notifyDestroyed() op om vernietigd te worden. Merk op dat resumeRequest() enkel vraagt aan de AMS om de MIDlet te reactiveren. De AMS beslist echter zelf of het al dan niet de MIDlet zal reactiveren en wanneer. Bij reactivatie wordt de startApp() terug opgeroepen. notifyPaused() en notifyDestroyed() daarentegen zorgen voor onmiddellijke transacties naar de nieuwe toestand. Daarbij worden pauseApp() en destroyApp() niet opgeroepen. De code voor een betere basis MIDlet ziet er als volgt uit: import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class BettereMIDlet extends MIDlet { private Display display; public BettereMIDlet(){} protected void destroyApp(boolean unconditional) throws MIDletStateChangeException { exitApp(); // Roep de cleanup code } protected void pauseApp(){ // Opgeroepen wanneer het systeem de MIDlet pauzeert } protected void startApp() throws MIDletStateChangeException { if(display == null){ initApp(); // Voer de eenmalige initialisatie uit } // Voeg de activatiecode hier toe } private void initApp(){ display = Display.getDisplay(this); // Voeg de initialisatiecode toe } public void exitApp(){ // Voeg de cleanup code toe notifyDestroyed(); // vernietig de MIDlet }


52

} In tegenstelling tot de BasisMidlet klasse, definieert de BettereMIDlet klasse een initApp() methode voor eenmalige initialisatie (die uitgevoerd wordt bij de eerste oproep van startApp()) en een exitApp() methode voor gecentraliseerde vrijgave van bronnen. Voor het ontwikkelen van MIDlet clients verwijzen we u naar hoofdstuk 2 van de J2ME Tutorial [33].

3.3.4

Het Xlet model

Een Xlet is nog een ander soort beheerde applicatie. Origineel waren Xlets een onderdeel van de Java TV API, maar ze werden overgenomen voor gebruik in PBP en PP binnen J2ME. Net zoals MIDlets worden Xlets beheerd door specifieke AMS. De Xlet levenscyclus. De hoofdklasse van een Xlet implementeert de javax.microedition.xlet.Xlet interface, die vier levenscyclus notificatiemethoden declareert: initXlet(), startXlet(), pauseXlet() en destroyXlet(). Merk op dat, in tegenstelling tot applets of MIDlets, een Xlet geen bijzondere klasse moet uitbreiden. Net zoals applets hebben Xlets vier mogelijke toestanden (zie figuur 3.8): • loaded : de Xlet instantie is geconstrueerd, maar initialisatie heeft nog niet plaatsgevonden • paused : de Xlet is ge¨ınitialiseerd, maar onactief • active: de Xlet is actief • destroyed : de Xlet is beëindigd en klaar voor garbage collection Wanneer de AMS een Xlet creëert, heeft ze de loaded toestand. Snel na de constructie roept de AMS de Xlets initXlet() methode op, en geeft ze de XletContext door, die de Xlet moet gebruiken om te interageren met zijn operating context. Deze parameter is noodzakelijk, omdat de Xlet geen specifieke basisklasse uitbreidt (zoals het geval is bij applets en MIDlets). Na de initialisatie verandert de toestand van de Xlet naar de paused toestand. Verder gedraagt een Xlet zich ongeveer zoals een MIDlet. Op een bepaald ogenblik activeert de AMS de Xlet en roept ze de startXlet() methode op, waarop de Xlet zijn user interface activeert en toegang verkrijgt tot de systeembronnen die ze nodig heeft. Hierna gaat ze over naar de active toestand. Desactivatie vindt plaats, wanneer de Xlet’s toestand verandert van active naar paused. Wanneer de AMS de Xlet desactiveert, roept ze de Xlet’s pauseXlet() methode op. Daarop geeft de Xlet zoveel mogelijk bronnen vrij. Als de Xlet zichzelf desactiveert, wordt de pauseXlet() methode echter niet opgeroepen. Een toestand van een Xlet kan op elk ogenblik veranderen naar de destroyed toesand. Als de AMS de Xlet vernietigt, roept ze de destroyXlet() methode. Net zoals MIDlets, kunnen Xlets soms hun vernietinging weigeren door een exceptie te gooien. Als een Xlet zichzelf vernietigt, wordt destroyXlet() niet opgeroepen. De code voor een basis Xlet ziet er als volgt uit:


Loaded

initXlet()

destroyXlet()

destroyXlet()

53

Paused

pauseXlet() startXlet()

Destroyed

destroyXlet()

Active

Figuur 3.8: Lifecycle van een Xlet import javax.microedition.xlet.*; public class BasisXlet implements Xlet { private XletContext context; public BasisXlet(){ // constructor, doe niet veel hier! } public void initXlet(XletContext context) throws XletStateChangeException { // Opgeroepen door het systeem om Xlet te initialiseren this.context = context; // houd de context bij // Voeg hier andere initialisatiecode toe } public void destroyXlet(boolean unconditional) throws XletStateChangeException { // Opgeroepen door het systeem om de Xlet te vernietigen } public void pauseXlet(){ // Opgeroepen wanneer het systeem de Xlet pauzeert // zoveel mogelijk bronnen vrijgeven } public void startXlet() throws XletStateChangeException { // Opgeroepen wanneer het systeem de Xlet activeert


54

// vraag hier pas de bronnen } } De Xlet Context In het Xlet model interageert een applicatie met zijn operating context door middel van een object dat de javax.microedition.xlet.XletContext interface implementeert. Deze interface declareert vijf methodes: getContainer() verkrijgt het UI object van de applicatie; getXletProperty() geeft de initialisatie parameters terug; notifyDestroyed() verandert de Xlet’s toestand naar destroyed ; notifyPaused() verandert de toestand naar paused en resumeRequest() vraagt de AMS om de Xlet te reactiveren. Een Xlet gebruikt de resumeRequest(), notifyDestroyed() en notifyPaused() methodes op dezelfde manier als een MIDlet. Een betere versie van de basis Xlet code ziet er als volgt uit: import javax.microedition.xlet.*; public class BettereXlet implements Xlet { private XletContext context; public BettereXlet(){} public void destroyXlet(boolean unconditional) throws XletStateChangeException { exitXlet(); // Roep de cleanup code op } public void exitXlet(){ // Voeg de cleanup code hier toe context.notifyDestroyed(); // Vernietigt de Xlet } public XletContext getContext(){ // Getter van de context return context; } public void initXlet(XletContext context) throws XletStateChangeException { this.context = context; // store the context // Voeg de initialisatiecode hier toe } public void pauseXlet(){ // Voeg de pauzeercode hier toe } public void startXlet() throws XletStateChangeException {


55

// Voeg de code toe die moet uitgevoerd worden bij elke activatie } } Voor het ontwikkelen van Xlets voor het Multimedia Home Platform verwijzen we u naar de MHP tutorial [34].

T-COMMERCE EN ZIJN TOEPASSINGEN

56

Hoofdstuk 4

T-commerce en zijn toepassingen In hoofdstuk 2 werd het belang van platform-onafhankelijke applicaties reeds aangetoond. Ook werden de karakteristieken van digitale televisie al behandeld met zijn sterktes en zwaktes. In dit hoofdstuk zullen wij ons nu toespitsen op één bepaalde dienst die kan aangeboden worden via digitale televisie, namelijk t-commerce. Deze vrij recente term werd nog maar onlangs (april 2006) gedefinieerd in de Wikipedia [7]: T-commerce is de naam die gebruikt wordt voor het aankopen van producten en diensten via ” een TV. Door gebruik te maken van de afstandsbediening kan je dingen bestellen. T-commerce lijkt dus op E-commerce, maar dan via een televisietoestel. Het is echter alleen mogelijk met interactieve digitale TV, niet met analoge TV’s.” De verzameling van de hierboven vermelde producten is enorm groot. De producten kunnen gaan van ontastbaar en goedkoop (zoals een audioclip) tot materieel en duur (zoals een wagen). De hoeveelheid diensten, die kunnen ’verkocht’ worden bij t-commerce, is echter nog veel groter. Ze variëren van eenvoudig (een dagelijks weerbericht waarop de gebruiker zich kan abonneren) tot bijzonder complex (aan- en verkoop van producten in het genre van eBay, [35]). Het kan zelfs gaan om gratis diensten, waarbij de provider niet rechtstreeks winst maakt. Een voorbeeld hiervan is een interactieve applicatie, waarmee je je reisfoto’s kunt bekijken die je online opgeslagen hebt. Binnen deze applicatie zou er dan wel een mogelijkheid moeten bestaan om de foto’s te kunnen betellen. Op deze manier kan deze gratis dienst een erg winstgevende zaak worden. Bovenstaande definitie geeft als enig verschilpunt tussen t-commerce en e-commerce het te gebruiken medium. In hoofdstuk 2 werd reeds een algemene vergelijking gemaakt tussen digitale televisie en de computer. In sectie 4.1 van dit hoofdstuk zullen we ons nu toespitsen op één bepaalde dienst, namelijk t-commerce en zullen we deze vergelijken met e-commerce. In sectie 4.2 zullen enkele bestaande t-commerce applicaties bestudeerd worden. Sectie 4.3 sluit af met een samenvatting van de belangrijkste toepassingen van t-commerce.

4.1

De voor- en nadelen van t-commerce ten opzichte van ecommerce

Het grootste verschil tussen t-commerce en e-commerce is, zoals de Wikipedia al zei, dat tcommerce via televisie gebeurt en e-commere via de computer. Nu moeten t-commerce en

4.1 De voor- en nadelen van t-commerce ten opzichte van e-commerce

57

e-commerce eigenlijk niet bekeken worden als competitief, maar eerder als complementair. Door ze in combinatie met elkaar te gebruiken kunnen de sterktes van elk medium benuttigd worden. Zo zal een nog grotere doelgroep bereikt worden en zullen nog meer faciliteiten aangeboden kunnen worden. Als daarenboven een bedrijf investeert in een platform-onafhankelijke applicatie die tegelijk bereikbaar is voor digitale televisie én computers, zullen de kosten beperkt blijven en zal de applicatie enorm winstgevend zijn. Een platform-onafhankelijke applicatie zorgt er namelijk voor dat de content slechts één keer gecreëerd moet worden, dat de server-zijde weinig aanpassingen nodig heeft en dat er geen inconsistentie zal zijn tussen de data voor de verschillende clients. Dergelijk verkoop van producten via computer en televisie zou nog meer geoptimaliseerd kunnen worden door de integratie van m-commerce (mobile commerce); dit is het verkopen van producten en diensten via handheld apparaten. Nog meer apparaten zouden in de dienst betrokken kunnen worden zoals deze vermeld in hoofdstuk 3. Zo zouden gebruikers, naast het reserveren van een parkeerplaats met de mobiele telefoon, ook de mogelijkheid moeten krijgen dit te doen met het navigatiesysteem van de wagen. Deze dienst zou dan automatisch de dichtsbijzijnde vrije parkeerplaats moeten reserveren in de buurt van de bestemming van de gebruiker. Het navigatiesysteem zou de wagen dan eenvoudig kunnen leiden naar de gereserveerde parkeerplaats. We hebben besloten om in dit hoofdstuk enkel een vergelijking te maken tussen e-commerce (dat tegenwoordig enorm populair is en erg winstgevend) en t-commerce (dat in de nabije toekomst een belangrijke rol kan spelen door de sterke groei van digitale televisie). Eerste geven we de belangrijkste voordelen van t-commerce ten opzichte van e-commerce. Daarna bespreken we de nadelen. De voordelen • Traditionele televisie biedt een rijke multimedia ervaring met cultureel relevante en actuele informatie. Zelfs zonder het interactieve aspect heeft ze een groot aanbod aan zenders met een grote waaier van diverse programma’s. • De broadcast provider kan zelf beslissen welke applicaties beschikbaar zijn. Daardoor komt er geen overvloed aan informatie en diensten (zoals bij het internet) waarin computergebruikers kunnen verdwalen. Bij iTV kunnen de providers het aantal applicaties beperken, waardoor de gebruiker sneller zijn weg zal vinden naar de dienst die hij wil. • Interactieve televisieapplicaties vertonen veel meer eenvoud dan de meeste applicaties voor computer. Ze bevatten enkel de kerninformatie en geen ellenlange tekst (omwille van een beperkte schermgrootte en een soms gelimiteerde telefoonmodemverbinding) en zijn voorzien van een eenvoudige user interface. De navigatie wordt eenvoudig gehouden door het gebruik van kleurenknoppen (rood, groen, geel en blauw). Door het definiëren van ontwerprichtlijnen vertonen verschillende applicaties gelijkaardige user interfaces, wat het nieuwe gebruikers veel gemakkelijker maakt. • In tegenstelling tot computergebruik wordt televisie bekeken in een ontspannen omgeving. De gebruiker kan gerelaxeerd in zijn zetel informatie opvragen en bekijken, wat het een stuk aangenamer maakt dan dit te moeten doen in zijn werkomgeving op een harde stoel. • Doordat veel meer televisies in omloop zijn, wordt een grotere groep gebruikers aangetrokken. Bepaalde groepen, zoals invaliden en bejaarden, zijn minder vertrouwd met


58

computers en zullen er daarom minder gebruik van maken om aankopen te doen. Ook hebben bepaalde mensen, omwille van financiële redenen, nog steeds geen computer. • Vele gebruikers vinden computers onveilig en onbetrouwbaar omwille van het bestaan van virussen, worms,. . . Ze durven ook wel eens vastlopen. Bij televisie is dit niet het geval. Televisiekijkers zullen dus meer vertrouwen stellen in t-commerce dan in e-commerce. Ook is bijna iedereen, van jong tot oud, vertrouwd met een televisie, wat niet kan gezegd worden van computers. Ze zijn minder gebruiksvriendelijk. • Er is sprake van een sterkere interactiviteit. Tijdens het TV-kijken kan de gebruiker, om het even wanneer, beslissen een aankoop te doen. Tijdens het bekijken van een film kan de gebruiker bijvoorbeeld rechtstreeks overgaan naar een t-commerce applicatie, die de DVD of gadgets van de film aanbiedt. • Met de komst van internet browsers op digitale televisie, en applicaties om te chatten of te mailen, zal iTV stilaan de computer gedeeltelijk vervangen. Als een gebruiker snel even zijn mail wil controleren, of snel een aankoop wil doen, zal hij hiervoor eerder de televisie gebruiken dan de computer. De televisie is meteen opgestart en staat meestal ook centraal in de woonkamer, terwijl de computer soms enkele minuten nodig heeft om op te starten en dikwijls in een afgezonderde kamer staat. • Televisiekijken is dikwijls een groepsgebeuren, wat dit medium bijzonder interessant maakt voor groepsdiensten. Als gebruikers een product (een wagen bijvoorbeeld) of een dienst (video-on-demand) willen aanschaffen voor het hele gezin, kan dit via iTV veel gemakkelijker gebeuren. Zo kan een gezin, dat een wagen wenst te kopen, multimedia materiaal over verschillende wagens bekijken vooraleer over te gaan tot een bestelling. Of zoals in de ge¨ımplementeerde applicatie uit hoofdstuk 6 kan een groep mensen eerst enkel filmtrailers bekijken voordat cinematickets aangeschaft worden. • Digitale televisie is ook ideaal voor impulsieve aankopen. Met enkele toestdrukken kan een product besteld worden. Dus, als de gebruiker onmiddellijk na het zien van een fantastisch reclamespotje het aangeboden product wil kopen, dan kan hij dat en zal hij dat ook onmiddellijk doen. Als hij daarentegen eerst zijn computer moet opstarten, kan hij zich reeds bedenken en inzien dat hij dergelijk product eigenlijk niet echt nodig heeft, of dat het behoorlijk duur is. Aan t-commerce zijn er natuurlijk niet alleen positieve aspecten. Er zijn zelfs bepaalde voordelen, die ook als nadeel beschouwd kunnen worden. Zo kan de eigenschap, dat televisie kijken een groepsgebeuren is, een nadeel zijn voor een gebruiker die gesteld is op zijn privacy tijdens het shoppen. We merken op dat de nadelen die zullen opgesomd worden, dikwijls weggewerkt kunnen worden door de dienst beschikbaar te maken voor andere platformen, zoals computer of mobiele telefoon. Zo kan elk platform al zijn voordelen optimaal benutten en worden de nadelen van bepaalde platformen minder opgemerkt.


59

De nadelen • De resolutie van een televisiescherm is beduidend lager dan de resolutie van een computerscherm, daardoor zal de beeldkwaliteit ook stukken lager zijn. Als bijvoorbeeld, bij de aankoop van een digitale camera, testfoto’s van verschillende camera’s vergeleken willen worden, zal digitale televisie hiervoor niet het geschikte middel zijn. • Door de grotere kijkafstand zal de informatie groter moeten afgebeeld worden, met als gevolg dat er minder informatie op het scherm weergegeven kan worden. Als een gebruiker uitgebreide informatie wil over een product of dienst zorgt dit voor problemen. De gegevens kunnen wel over verschillende schermen verspreid worden, maar dit verstoort de structuur en het algemene overzicht over de gegevens. • Bij e-commerce kunnen de producten aantrekkelijker voorgesteld worden. Flash animaties kunnen de webwinkel wat opfleuren en de gebruiker heeft soms de mogelijkheid om producten in 3D te zien. Deze mogelijkheid bestaat (nog) niet bij digitale televisie. • Zoals in hoofdstuk 2 besproken hebben set-top boxen bij digitale televisie minder geheugen en rekenkracht dan de hedendaagse computers. Dit heeft tot gevolg dat de appicaties minder geavanceerd kunnen zijn en afhankelijker van de server. Bij een computer zou bijvoorbeeld een berekening van de totale kostprijs, inclusief kortingen, berekend kunnen worden aan de client-zijde, terwijl dit bij de digitale televisie beter aan de server-zijde gebeurt. • Ook zagen we reeds dat digitale televisie beperkt is qua inputmogelijkheden. Tekstinformatie moet op de sms-manier ingegeven worden, en een muis bestaat er ook al niet. De gebruiker zal dus minder snel kunnen interageren met de applicatie en de tekstinput willen beperken. Deze beperkte gegevensinvoer van de gebruiker kan voor bepaalde applicaties een nadeel zijn. Een voorbeeld hiervan is een applicatie in het genre van eBay, waarbij een product dat een gebruiker wenst te verkopen gedetailleerd moet omschreven worden. • Bij digitale televisie zal de gebruiker zijn aandacht verdeeld zijn onder de gebroadcaste videobeelden en de applicatie. Bij de computer kan de gebruiker zich echter volledig focussen op de applicatie, waardoor de gebruiker geen enkele informatie mist die getoond wordt. Als bij het opstarten van een bepaalde applicatie bijvoorbeeld reclame wordt getoond, zal deze veel meer impact hebben op computergebruikers dan op TV-kijkers. • Ondertussen bestaat e-commerce al een hele tijd. Dit zorgt ervoor dat vele gebruikers, die interesse hebben in het kopen van producten vanop afstand, al vertrouwd zijn met de bestaande methoden, namelijk e-commerce. Omwille van deze inburgering zullen zij moeilijker de stap maken van e-commerce naar t-commerce. • Terwijl e-commerce applicaties zoals Amazon.com [41] overal bereikbaar zijn vanaf elke computer, onafhankelijk van het besturingssysteem, hangen de iTV applicaties af van de kabeloperator. Zij beslissen welke applicaties de gebruikers ter beschikking hebben.

4.2 Bestaande t-commerce applicaties

4.2

60

Bestaande t-commerce applicaties

Bij een zoektocht naar bestaande t-commerce applicaties bleken weinig bedrijven bereid tot het geven van informatie over hun interactieve televisie applicaties. De meeste bedrijven beperkten zich tot het beschrijven van de diensten die ze aanbieden, maar gaven geen informatie prijs over hun werking. Twee bedrijven waren hierop een uitzondering en gaven meer uitleg over de implementatie van hun t-commerce applicaties: Pontegra t-commerce en Ortikon interactive. Beide implementeren een browser die een deelverzameling van DVB-HTML ondersteunt, zoals besproken werd in sectie 2.3.3. In deze sectie zullen deze beide applicaties besproken worden. Sectie 4.3 zal nog andere voorbeeldapplicaties vermelden bij hun corresponderend toepassingsgebied.

4.2.1

Pontegra t-commerce

Figuur 4.1: Pontegra t-commerce Oorspronkelijk was Pontegra t-commerce (zie figuur 4.1) in het bezit van NIONEX [36], maar in maart 2006 heeft empolis ([37]) het iTV gedeelte van NIONEX (met daarbij de Pontegra TV browser) overgenomen. De Pontegra TV browser van NIONEX bedekt een volledig compatibele deelverzameling van DVB-HTML. De browser is een DVB-J applicatie die, zoals elke andere DVB-J applicatie, ingeladen kan worden op elke MHP 1.0.2 compatibele set-top box. Figuur 4.2 geeft de DVB-HTML deelverzameling weer die ondersteund wordt door de Pontegra browser (Pontegra DVB-HTML). Deze figuur toont ook, op een eenvoudige manier, de onderlinge relatie tussen DVB-HTML en HTML 4.0 die gespecifieerd is door W3C. Er wordt in de figuur ook duidelijk gemaakt dat de huidige Web browsers niet exact HTML 4.0 ondersteunen en bovendien sterk in uiterlijk kunnen verschillen. Er werd gekozen om slechts een deelverzameling van DVB-HTML te ondersteunen omwille van enkele redenen. De browser is ontworpen voor de hedendaagse set-top boxen en DVB-HTML applicaties. Ze zal geleidelijk aangepast worden aan de volle DVB-HTML specificatie van zodra krachtigere MHP set-top boxen (op vlak van geheugen, rekenkracht,. . . ) beschikbaar zullen

4.2 Bestaande t-commerce applicaties

61

Web browsers W3C HTML

Pontegra DVB-HTML DVB-HTML

Figuur 4.2: Situering van de Pontegra DVB-HTML deelverzameling zijn. De volledige DVB-HTML specificatie voorziet namelijk veel mogelijkheden en elementen die overbodig zijn voor huidige iTV-applicaties of diensten in de nabije toekomst. Tabel 4.1 stelt alle DVB-HTML modules voor die ondersteund worden door de Pontegra browser. De reden waarom Pontegra bepaalde DVB-HTML modules niet ondersteunt vindt u in [38][39]. We vervolgen met het geven van enkele functionaliteiten van de Pontegra browser. Pontegra voorziet content transmissie in twee richtingen. Zo interpreteert ze de prefix (http, https, file of dvb) van elke URI en op basis hiervan laadt ze de URI via de transport stroom of het return kanaal. Zo wordt bijvoorbeeld dvb:// gebruikt voor push-georiënteerde content, die via de transportstroom wordt ingeladen, en http:// voor peer-to-peer content, die via het return kanaal wordt ingeladen. Bij het realiseren van een dienst is er altijd keuze uit twee mogelijke transmissiemethoden: de relatief dure uni-directionele dvb-transmissie voor gemeenschappelijke broadcast content of de goedkopere bi-directionele peer-to-peer internet transmissie voor gepersonaliseerde content. Als het http-protocol gebruikt wordt, kunnen geavanceerde applicaties gerealiseerd worden door gebruik te maken van Java Server Pages op de server die zich in het internet bevindt. Dit is dezelfde benadering als bij standaard internet sites, waar de complexe applicatielogica gescheiden wordt gehouden van de browser op de client PC. Pontegra ondersteunt secure HTTP-connecties via het internet door middel van HTTPS. HTTPS is eigenlijk HTTP over SSL (Secure Socket Layer) en maakt het verkeer beveiligd. Pontegra ondersteunt ook cookies voor het realiseren van sessies. Op deze manier kan gebruiker-specifieke informatie bewaard worden, wat nuttig kan zijn bij t-commerce. De Pontegra browser is ook voorzien van een plug-in mechanisme, waardoor news tickers, een digitale klok,. . . ook mogelijk zijn. Ook neemt de Pontegra browser slechts 200 kB in en voorziet ze speciale caching mechanismes om de content zo snel mogelijk in te laden.

4.3 Toepassingen

62

Tabel 4.1: De DVB-HTML modules DVB-HTML Module Ondersteund door Pontegra? Structure Ja Text Ja, met beperkingen Hypertext Ja List Neen Presentation Ja, met beperkingen Bi-directional text Neen Basic forms Ja Basic tables Ja Image Ja Client-side image map Neen Objects Ja, met beperkingen Frames Neen Target Ja I-frame Ja, met beperkingen Metainformation Ja Scripting Ja, met beperkingen Style Sheet Ja Style attribute Ja Link Ja Base Neen DVB Intrinsic Events Neen

4.2.2

Ortikon interactive

Dit bedrijf vertoont sterke gelijkenissen met Pontegra t-commerce en voorziet ook een browser die een deelverzameling van DVB-HTML ondersteunt. Het Ortikon ACE MHP-Platform (zie figuur 4.3) laat de creatie toe van on-demand, entertainment, informatie en communicatie diensten. Dit soort diensten helpt de netwerkoperatoren bij het lokken van nieuwe klanten en het verhogen van hun loyaliteit en de Average Revenue Per User (ARPU). De ARPU geeft de gemiddelde omzet per gebruiker aan van een operator of service provider. Het platform includeert alle technologieën voor het implementeren van de hedendaagse netwerkdiensten. Het is speciaal geschikt voor operatoren met volgende wensen: een snelle timeto-market, een integratie met bestaande systemen, een flexibele content creatie met standaard Web authoring tools en het gebruik van beschikbare internet content. De Ortikon browser is geschikt voor volgende diensten: Electronic Program Guide (EPG), nieuwsdiensten, shopping cart, pay-TV besteldiensten, e-mail, foto album, chat, games, thirdparty services,. . . Ortikon heeft op haar website [40] een handleiding ter beschikking gesteld tot het creëren van DVB-HTML documenten voor haar browser.

4.3

Toepassingen

Zoals we reeds vermeld hebben is het aantal toepassingen van t-commerce enorm groot. Volgens de definiëring die we eerder gaven, moet er enkel sprake zijn van de verkoop van een dienst of product. We kunnen de diensten eigenlijk opsplitsen in twee soorten. Deze waar rechtstreeks

4.3 Toepassingen

63

Figuur 4.3: Ortikon interactive voor moet betaald worden enerzijds, en anderzijds gratis diensten die onrechtstreeks winstgevend zijn. In het tweede geval gaat het bijvoorbeeld om een fotoapplicatie, waarbij gebruikers gratis hun foto’s vanop een server kunnen bekijken op televisie, en waarbij winst gecreëerd wordt, wanneer gebruikers foto’s bestellen. Diensten waar rechtstreeks voor betaald moet worden, zijn bijvoorbeeld het nieuws of een tijdschrift waarop gebruikers zich kunnen abonneren. We kunnen dus in het algemeen enkele eigenschappen van t-commerce opnoemen. Gebruikers moeten betalingen kunnen uitvoeren. Dit moet natuurlijk beveiligd gebeuren, wat besproken zal worden in hoofdstuk 5. Gebruikers moeten zich op één of andere manier ook aanmelden bij de applicatie. Minimaal houdt dit in dat een gebruiker enkel zijn betaalgegevens moet invullen (die dan niet op de server worden bijgehouden), maar in het beste geval kan een gedetailleerd profiel van de gebruiker bijgehouden worden aan de server-zijde. Profielbeheer en het personaliseren van de applicatie wordt later nog behandeld in hoofdstuk 5.

4.3.1

Push services

Hieronder worden diensten verstaan die informatie pushen naar de gebruiker. De gebruiker kan zich vooraf abonneren op een bepaalde push service (door het betalen van een bedrag). In ruil daarvoor krijgt hij dan de gewenste informatie zoals het nieuws, beursnoteringen, weersvoorspellingen,. . . Er kan ook een gedeelte van de push service gratis ter beschikking gesteld worden (zoals nieuwsflashes), terwijl een ander deel enkel toegankelijk is voor geregistreerde gebruikers met een abonnement (bijvoorbeeld alle gedetailleerde nieuwsfeiten). Het profielbeheer speelt hier een belangrijke rol. Zo zouden de interesses van een gebruiker opgeslagen kunnen worden in een profiel en zouden alle nieuwsfeiten, gerelateerd met deze interesses, eerst gepusht kunnen worden naar de gebruiker.

4.3.2

Entertainment & games

T-commerce kan ook teruggevonden worden in de entertainment & games sector. In plaats van de huidige televisiespelletjes, waarbij een smsje moet verstuurd worden of gebeld worden, zou de

4.3 Toepassingen

64

gebruiker nu interactief kunnen meespelen met zijn digitale televisie. Net zoals bij de traditionele spelletjes, zou de gebruiker dan ook een bepaald bedrag moeten betalen per deelname. Voor games kan het pay-to-play principe toegepast worden, waarbij de gebruiker per spelletje dat hij wil spelen, een bedrag moet betalen. Voorgaande betalingen kunnen op verschillende manieren uitgevoerd worden. Zo kan de gebruiker deze bedragen gewoon ingerekend krijgen in zijn telefoonrekening, maar ook kan de gebruiker telkens met een bankkaart betalen, waarbij dan de kredietkaartgegevens kunnen bijgehouden worden op de set-top box, zodat de gebruiker niet telkens opnieuw zijn gegevens moet ingeven.

4.3.3

T-banking

Naast online bankieren zal het in de toekomst ook mogelijk zijn om aan t-banking te doen. DigiBank ([43], zie figuur 4.4) geeft klanten toegang tot financiële diensten via iTV. DigiBank is ge¨ıntegreerd met de bestaande on-line banking engine van de bank, zodat gebruikers hun zelfde paswoorden en gebruikersnamen kunnen gebruiken om tot hun account toegang te verkrijgen. DigiBank voorziet alle aspecten van iTV banking, inclusief beveiliging, authenticatie, registratie, profielbeheer, advertising, gebruikersinteractie en schaalbaarheid.

Figuur 4.4: DigiBank

4.3.4

T-shopping

Dit is wellicht de belangrijkste toepassing van t-commerce: het effectief te koop aanbieden van producten. Zoals reeds eerder vermeld, kunnen deze producten ofwel materieel zijn (zoals boeken), ofwel ontastbaar (zoals digitale muziek). Het komt erop neer, dat de gebruiker met een virtueel winkelwagentje winkelt. Een van de meest bekende e-shopping applicaties is wellicht eBay [35], dat kopers en verkopers samenbrengt in één applicatie. BIAP maakt nu eBay ook toegankelijk voor digitale televisie [50]. Via de applicatie komt de gebruiker, die een bod geplaatst had op een bepaald artikel, ook onmiddellijk te weten of een andere gebruiker meer geboden heeft. Geregistreerde eBay gebruikers kunnen ook de huidige veilingen zien, hun koopgeschiedenis bekijken of verwittigd

4.3 Toepassingen

65

worden als hun bod het gehaald heeft. Door ofwel rechtstreeks gebruik te maken van de applicatie, ofwel tijdens het kijken van televisie, kunnen de gebruikers op elk moment interageren in de eBay markt. Navic t-commerce ([42], zie figuur 4.5) implementeert een applicatie, die kijkers toelaat maaltijden te bestellen van verschillende lokale restaurants zoals bijvoorbeeld Pizza Hut, en te betalen met hun kredietkaart. Kijkers kunnen er ook voor kiezen om hun kredietkaartnummers, adres en PIN code op te slaan op een beveiligde Navic server, die deze dan gebruikt bij het betalen van bestellingen. Om de veiligheid te garanderen worden de transacties volledig geëncrypteerd door de Navic encryptie machine die zich op de set-top box bevindt.

Figuur 4.5: Navic t-commerce Bij DigiTravel ([44], zie figuur 4.6) wordt de digitale televisie als reisbureau gebruikt. Het laat de verkoop toe van vluchttickets, autoverhuur, hotelreserveren,. . . via iTV. DigiTravel vraagt de gebruikers eerst, op een snelle en eenvoudige manier, zijn verlangens in te geven, en voorziet daarna een lijst met de reismogelijkheden. Digitale televisie laat ook toe fotoalbums te bekijken. De digitale foto’s worden met de computer op de server gezet en worden bekeken op de digitale televisie. Gebruikers hebben dan ook de mogelijkheid om foto’s te bestellen via televisie. Zo zouden oudere mensen (die in het algemeen geen gebruik maken van computers) bijvoorbeeld de mogelijkheid hebben om de reisfoto’s van hun kleinkinderen te bekijken en te bestellen via televisie. Een laatste interessant voorbeeld voor t-commerce is de bestelling van tickets voor concerten, festivals, cinema,. . . In hoofdstuk 6 wordt de Java Smart Ticket Demo voor het aankopen van cinematickets besproken. Terwijl de oorspronkelijk Demo applicatie beschikbaar is voor handheld apparaten, werd in het praktisch gedeelte van deze thesis de applicatie omgezet voor digitale televisie. Onder de extra mogelijkheden die digitale televisie biedt, valt ook het bekijken van de trailers van films waaruit men kan kiezen.

4.3 Toepassingen

66

Figuur 4.6: DigiTravel

4.3.5

Advertising

Bijna 70 % van de reclamebureaus denkt dat DVR’s (Digital Video Recorders) en VOD (Video ” On Demand) de doeltreffendheid van de traditionele 30-seconde reclamespot zal reduceren of vernietigen.” (Bron: [51]) Dit zou inderdaad wel een groot probleem kunnen zijn bij iTV. Maar anderzijds biedt digitale televisie ook wel nieuwe mogelijkheden. Zo is er het gebruik van tickers, die tijdens een uitzending reclameboodschappen tonen, of logo’s van sponsors bij een sportevent laten zien. Ook zou een gebruiker tijdens een reclamespotje, of tijdens het zien van een film, met één druk op de toets (red button interactivity genaamd), meer informatie kunnen opvragen over dat product uit het reclamespotje, of gadgets die bij de film horen. De gebruiker zal dus interactiever op de reclame kunnen ingaan. Hij kan bijvoorbeeld, bij het zien van een reclamespotje van een wagen, onmiddellijk een testrit aanvragen. Ook kunnen reclamebanners ingewerkt worden in bepaalde applicaties, zodat een gebruiker ze zeker niet kan negeren. DigiPromo ([45], zie figuur 4.7) laat bedrijven toe een interactie toe te voegen aan hun traditionele TV advertising. Het laat kijkers toe te interageren met de advertising. Zo kan de gebruiker meer informatie opvragen over het product of het zelfs onmiddellijk aankopen. DigiPromo kan gebruikt worden om nieuwe producten of diensten te promoten, gratis testproducten aan te bieden en basis marketonderzoek te verrichten. Interactieve televisie geeft advertisers de mogelijkheid om informatie snel en gemakkelijk aan de kijker aan te bieden. Televisie is een goed middel voor het demonstreren van nieuwe producten. Voor een aankoop van hoge kwaliteit zullen klanten investeren in tijd om verdere informatie te bekijken en meer te leren over de opties die het product hen biedt. Wanneer gebruikers extra interesse vertonen in bepaalde producten, kan dit bijgehouden worden en kunnen kortingsbonnen of productbrochures opgestuurd worden. Op deze manier kunnen advertisers aan beter marktonderzoek doen en worden ze enorm geholpen bij het opbouwen van een profiel van hun doelpulbiek. Het laat bedrijven dus toe de ROI (Return on Investment) te berekenen.

4.3 Toepassingen

67

Figuur 4.7: DigiPromo

4.3.6

PayTV

DigiPayTV ([48], zie figuur 4.8) is een MHP compatibele applicatie voor het aanbieden van PayTV diensten. DigiPayTV laat netwerk operatoren en broadcasters toe Pay TV, Pay Per View en Near Video On Demand (NVOD) diensten aan te bieden.

Figuur 4.8: DigiPayTV Bij DigiPayTV heeft de gebruiker de keuze uit meerdere starttijden en kan hij ook beslissen wat hij wenst te zien. Zo wordt de videotheek overbodig en worden boetes wegens laattijdig terugbrengen vermeden. Gebruikers bestellen vanuit het comfort van hun woning een film naar keuze. Een andere applicatie die PPV (Pay-Per-View) aanbiedt, is Espial Evo Pay-Per-View (PPV) [49]. Volledig ge¨ıntegreerd in de EPG kunnen gebruikers gemakkelijk pay-per-view gebeurtenissen bestellen.

4.3 Toepassingen

4.3.7

68

Gambling & lottery

DigiGamble ([46], zie figuur 4.9) maakt gokken mogelijk via iTV. DigiGamble vraagt de gebruiker een item te selecteren, geeft de huidige gokmogelijkheden weer en nodigt de kijker uit om in te zetten. Alle betalingen worden uitgevoerd met de DigiGamble secure payment engine en de kijker ontvangt een bevestigingsnummer wanneer zijn gok aanvaard werd door de bookmaker. Er wordt bovendien verzekerd dat de gebruikers data zien die up-to-date is.

Figuur 4.9: DigiGamble Zoals reeds eerder gezegd zijn impulsieve aankopen een belangrijk aantrekkingspunt van tcommerce. Zo zijn diensten, die korte maar intense interesse opwekken op bepaalde ogenblikken, ideaal voor de iTV wereld. Een voorbeeld daarvan is de loterij, waarvan DigiLottery ([47], zie figuur 4.10) als voorbeeldapplicatie gevonden werd.

Figuur 4.10: DigiLotto

PROFIELBEHEER EN BEVEILIGING

69

Hoofdstuk 5

Profielbeheer en beveiliging Bij t-commerce applicaties staat de klant centraal. Men moet er dus alles aan doen om deze zo tevreden mogelijk te stellen. Twee zaken zijn hierbij van bijzonder belang: profielbeheer en beveiliging. Een eerste verlangen van de gebruiker is dat de applicatie zo interessant mogelijk is, dat de applicatie als het ware aangepast wordt aan zijn behoeften. Daarvoor zal een gebruikersprofiel moeten opgemaakt worden van elke klant. Op basis van dit profiel kan dan de applicatie gepersonaliseerd worden. Het is echter niet noodzakelijk om profielen bij te houden om een applicatie te kunnen personaliseren. De personalisatie kan gebeuren op verschillende niveaus. We zullen dit bespreken in sectie 5.1. Een tweede verlangen is een absolute privacy. Gebruikers die geen veilig gevoel hebben over een t-commerce applicatie, zullen geen aankopen doen. De vraag is nu hoe dit kan gecreëerd worden. Topprioriteit bij de klant is: betalen op een beveiligde manier. Bovendien mag, naast gebruikersauthenticatie, de verstuurde data ook niet onderschept worden of zelfs aangepast. Sectie 5.2 behandelt deze verschillende aspecten van beveiliging voor t-commerce applicaties.

5.1

Profielbeheer

Bij commerce applicaties wordt het steeds belangrijker inzicht te krijgen in de wensen van de gebruiker. Deze zal ook via verschillende apparaten toegang kunnen krijgen tot de applicatie: enerzijds e-commerce, anderzijds t-commerce, maar in de toekomst zullen meerdere mogelijkheden hun intrede doen. Door dit gecombineerd gebruik zal een nog beter beeld van de gebruiker geschetst kunnen worden. Volgens [52] draait het in de huidige economie niet meer om het creëren van zoveel mogelijk winst, maar eerder om het aantrekken van zoveel mogelijk klanten. Hoe meer klanten zich in de databank van een onderneming bevinden, hoe beter. Naast de omvang van het gebruikersbestand is ook de stabiliteit hiervan van groot belang: een klant moet immers zo lang mogelijk klant blijven. Dit kan gerealiseerd worden door het creëren van een gedetailleerd profiel, waardoor inzicht kan verkregen worden in de wensen en gedragingen van die klant. Door het analyseren van de data in het gebruikersbestand is het mogelijk om actief in te gaan op de wensen van de klant. Op deze manier wordt door beide partijen winst behaald. Het opbouwen van klantenkennis heeft de ontwerper de mogelijkheid de applicatie te personaliseren, waardoor de bezoekers zullen terugkeren en hun voorkeuren duidelijk blijven maken. Het uiteindelijke

5.1 Profielbeheer

70

doel is dus niet het creëren van winst, maar het vergroten van de waarde van het bedrijf en het investeren in continu¨ıteit. Eerst en vooral, in sectie 5.1.1, gaan we dieper in op het identificeren van klanten. Daarna, in sectie 5.1.2 zal personalisatie besproken worden. Naast verschillende personalisatietechnieken worden ook verschillende personalisatieniveaus beschreven.

5.1.1

Het identificeren van klanten

Op verschillende manieren kunnen klanten in contact komen met het bedrijf. Traditioneel is dit meestal door een winkelbezoek, via telefoon of via fax. Maar in deze moderne tijd gebeurt dit ook vaak via e-commerce. Voordelen van e-commerce, en andere toekomstige verkoopmanieren zoals t-commerce en m-commerce, zijn dat het gedrag van de klanten veel beter gevolgd en bewaard kan worden. Het gebruik van smartcards is hiervan een toepassing. Een smartcard kan gedefinieerd worden als een draagbaar medium, dat informatie bevat van de houder.Deze informatie kan op verschillende plaatsen opgevraagd worden. Voorbeelden van smartcards zijn bankkaarten en digitale identiteitskaarten, die respectievelijk betalingen en authenticatie toelaten voor e-commerce en t-commerce. Een belangrijk voordeel van de smartcard is dat klanten op deze manier gevolgd kunnen worden over verschillende kanalen. Zo ontstaat een rijk beeld van het koopgedrag van de klanten. Een supermarkt kan niet enkel nagaan wat een klant koopt, maar ook waar en wanneer. De smartcard heeft echter ook een nadeel voor de klant: hij verliest een stuk van zijn privacy. Het identificeren, volgen en opslaan van klantgegevens leidt tot een profiel van de klant. Het profiel geeft inzicht in de voorkeuren, de wensen en het gedrag van de klanten. Des te rijker het profiel is, des te beter de klant gekend is en hoe beter op zijn behoeftes kan ingespeeld worden. Opdat een klant snel zou ge¨ıdentificeerd kunnen, worden kan gebruik gemaakt worden van verschillende types informatie die leiden tot een snelle identificatie van de klant. Deze verschillende delen van een gebruikersprofiel zijn: 1. klantgegevens: Dit kunnen zowel expliciete als impliciete gegevens zijn, die verkregen worden door het bezoek van de gebruiker aan de applicatie. Expliciete gegevens worden door de klant zelf ingevuld, terwijl impliciete gegevens afgeleid worden uit de frequentie en het tijdstip van gebruik van de applicatie en het aankoopgedrag. Deze gegevens kunnen ook afkomstig zijn van smartcards zoals een digitale identiteitskaart of een bankkaart. 2. voorspeld gedrag: Dit zijn gegevens, die voorspeld kunnen worden na het analyseren van de klantgegevens. Dit kan bijvoorbeeld door gedrag van klanten met analoge klantgegevens te linken met elkaar. 3. bezoekspecifiek gedrag Dit zijn de routes die de gebruiker volgt tijdens het gebruik van de applicatie, de tijd die de gebruiker spendeert op de onderdelen van de site, en de zoekacties die hij eventueel uitvoert. 4. toestelgegevens Het profiel kan ook informatie bijhouden over de toestellen de gebruiker connectie maakt met de applicatie en de tijdstippen waarop dit Bepaalde toestellen geven zelfs bijkomende informatie prijs over de gebruiker. elke set-top box een unieke code, waarmee het toestel ge¨ıdentificeerd kan worden.

waarmee gebeurd. Zo bevat Bij MHP

5.1 Profielbeheer

71

1.1.2 zou het zelfs mogelijk zijn om de postcode van de gemeente te achterhalen, waarin de set-top box zich bevindt. We merken op dat dergelijke toestelgegevens eerder beperkt zijn bij e-commerce, waar het besturingssysteem en het IP adres bijvoorbeeld achterhaald kunnen worden. Technieken om klanten te identificeren Bij e-commerce zijn de twee meest gebruikte technieken om klanten te identificeren het gebruik van een login en het bijhouden van cookies aan de client zijde. Bij de eerste methode kan de gebruiker zich identificeren door het ingeven van een login/paswoord combinatie, waarop het passende profiel uit de databank aan de server-zijde kan opgeroepen worden. Bij de tweede methode wordt aan de client zijde een klein bestandje opgeslagen met daarin gegevens, waardoor de applicatie de gebruiker kan identificeren. Bij t-commerce bestaan er meerdere mogelijkheden. We beschrijven hierna de verschillende identificatietechnieken voor t-commerce. • Het gebruik van een login: Deze techniek, die ook bij e-commerce het meest voorkomt, is waarschijnlijk de beste manier om de gebruiker te identificeren. Er bestaat zekerheid over de gebruiker, tenzij iemand anders zijn login en paswoord gebruikt. Nadelen van deze techniek zijn: – De gebruikers moeten veel informatie over zichzelf prijsgeven. Privacy is enorm belangrijk en daardoor durven gebruikers soms wel eens opzettelijk verkeerde informatie ingeven. – De server moet op een veilige manier al deze informatie kunnen bijhouden. Het is niet de bedoeling dat de gegevens bemachtigd worden door derden of verloren gaan. Belangrijke voordelen zijn: – er kan veel klantinformatie worden bijgehouden. Door de grote opslagmogelijkheden aan de server-zijde kan een volledig profiel in detail bewaard worden. – de login is toestelonafhankelijk. Hetzelfde gebruikersprofiel kan ook gebruikt worden bij inloggen vanaf een andere digitale televisie, of computer, of mobiele telefoon. – de login is persoonsgebonden. Zo zal in een gezin met één televisietoestel ieder gezinslid een andere login hebben, waardoor we geen groepsgebonden profiel krijgen zoals bij de andere identificatietechnieken. • Het gebruik van cookies: Net zoals bij e-commerce kan hier ook gebruik gemaakt worden van cookies die worden opgeslagen op de set-top box. Dit kan door bepaalde gegevens achter te laten in het persistente geheugen van de set-top box. De nadelen van deze techniek zijn: – Cookies kunnen niet herbruikt worden op een ander toestel. Dus als persoonlijke gegevens opgeslagen worden op de set-top box thuis, kunnen die niet herbruikt worden op een ander tv toestel, op de mobiele telefoon, op de computer. De gebruiker zal dus eigenlijk een een profiel creëren per toestel waarmee hij werkt.

5.1 Profielbeheer

72

– Door de beperkte geheugenopslag op de set-top box zullen de cookies heel regelmatig verwijderd worden en dus hun functionaliteit verliezen. Dit kan zelfs gebeuren tijdens het uitvoeren van een applicatie. Daardoor kan een applicatie plots volledig van layout en inhoud veranderen, doordat het profiel (dat in de verwijderde cookie zat) niet meer gevonden wordt. Het gevolg is een ongepersonaliseerde applicatie. – De cookies zijn niet persoonsgebonden, maar groepsgebonden. Gebruikers met een verschillend profiel kunnen gebruik maken van dezelfde digitale televisie, waardoor het profielbeheer niet meer correct zal verlopen. Er zou in zo’n geval wel een profiel kunnen opgesteld worden van een gezin bijvoorbeeld. De voordelen van deze techniek zijn: – elke set-top box ondersteunt het persistent opslaan van data, en cookies worden dus altijd ondersteund. Bij e-commerce is dit niet het geval doordat niet alle browsers cookies ondersteunen. – er zijn geen uitgebreide en goed beveiligde databanken nodig aan de server-zijde. Dit is kostenbesparend. – vele gebruikers weigeren een account aan te maken omwille van hun privacy. In zo’n geval blijven cookies de enige manier om stiekem een gebruikersprofiel bij te houden. • Identificatie op basis van tijdstip en televisieprogramma: Bij digitale televisie is er de extra mogelijkheid om de actieve gebruiker te associëren met het huidig tijdstip en het huidig televisieprogramma. Zo kan een gebruiker, die in de vroege avond reeds televisie kijkt een kinderprofiel gegeven worden, terwijl late kijkers een volwassen profiel toegewezen krijgen. Het soort televisieprogramma dat de gebruiker bekijkt, kan ook bijdragen aan het gebruikersprofiel. Een gebruiker die een sportprogramma bekijkt, kan een sportief-gericht profiel toegewezen krijgen. Nadelen van deze techniek zijn: – een gebruiker die een snelle aankoop wil doen, hiervoor zijn televisie aanzet en toevallig op een kinderprogramma terecht komt, zal een kinderprofiel toegewezen krijgen. Hij zal dan in de t-commerce applicatie een kind-vriendelijke interface te zien krijgen, waarbij promoties op kinderartikelen getoond worden. Dit is natuurlijk niet de bedoeling. – heel wat programma’s bereiken een breed publiek, waardoor de gebruikers moeilijk te profileren zijn. Voordelen zijn: – er moet, noch aan de client-zijde, noch aan de server-zijde, informatie bijgehouden worden. Het is daarom vrij eenvoudig te realiseren. De gegevens van het huidige televisieprogramma kunnen eventueel rechtstreeks uit de EPG gehaald worden. – het koppelen van een gebruiker aan een televisieprogramma is uniek voor digitale televisie. Bij m-commerce en e-commerce kan deze techniek niet toegepast worden. Ook is het identificeren van een gebruiker op basis van tijdstip daar minder doeltreffend. • Identificatie op basis van toestelgegevens: De set-top box bevat bijkomende informatie (zoals een unieke code, de postcode van de gemeente waarin de set-top box zich bevindt,. . . ) die gebruikt kan worden bij de gebruikersidentificatie. Zo kunnen gebruikers

5.1 Profielbeheer

73

op basis van hun postcode een bepaald profiel krijgen. Zo kan, bij het personaliseren van een nieuws applicatie, het regionaal nieuws eerst getoond worden. Een gebruiker van een cinema ticket dienst krijgt enkel de filmzalen uit zijn omgeving te zien. Door de unieke code van de set-top box kan een gezin met volledige zekerheid ge¨ıdentificeerd worden. Nadelen van deze techniek zijn: – de set-top box kan informatie zoals de postcode verborgen houden voor de applicatie – het opvragen van de postcode is pas mogelijk vanaf MHP 1.1.2, terwijl de meeste hedendaagse set-top boxen MHP 1.0.2 ondersteunen – de identificatie is niet persoonsgebonden, maar gebeurt per set-top box Voordelen daarentegen zijn: – hoewel bij e-commerce het IP adres gebruikt kan worden als unieke identificator, zal deze techniek daar niet zo doeltreffend zijn omdat dit IP adres variabel kan zijn en locatiegegevens hieruit niet onmiddellijk afleidbaar zijn. Deze techniek is dus enkel voor t-commerce van toepassing. – dit is de enige 100 % betrouwbare techniek. Bij de login techniek kan de gebruiker opzettelijk verkeerde gegevens ingevuld hebben, bij de cookie techniek kunnen cookies plots verwijderd worden, en bij de techniek op basis van tijdstip en televisieprogramma kan, zoals voordien reeds vermeld in een voorbeeld, ook een verkeerde conclusie getrokken worden. We merken op dat er ook een combinatie van voorgaande technieken mogelijk is, zodat ze complementair gebruikt kunnen worden.

5.1.2

Personalisatie

Personalisatie is het op maat aanbieden van applicatiecontent aan individuen of groepen van personen, gebaseerd op profielen, demografische gegevens en transacties in het verleden. Onder deze content vallen, naast bepaalde figuren en tekst, ook klantspecifieke producten en diensten. Het doel van personaliseren is het creëren van een wederzijdse kennisuitwisseling tussen bedrijf en klant, het verbeteren van de gebruiksvriendelijkheid van de applicatie door het bedrijf en het garanderen van toekomstig gebruik van de applicatie door de klant. Een belangrijk onderscheid kan gemaakt worden tussen personalisatie en customisatie. Customisatie is het aanpassen van een applicatie aan de persoonlijke voorkeuren van een gebruiker. De gebruiker kiest dan bijvoorbeeld zelf welke onderwerpen beschikbaar moeten zijn op de intropagina van de applicatie. Bij personalisatie wordt de content en weergave van de applicatie aangepast aan de verwachte wensen van de gebruiker. Het belangrijkste verschil zit in de activiteit. Bij customisatie is de gebruiker actief, bij personalisatie de applicatie. Personalisatie kan op vier niveaus plaatsvinden [53]. We behandelen ze hierna in volgorde van toenemende complexiteit. 1. Personalisatie zonder profielen: Op dit niveau is geen profiel aanwezig van de gebruiker. Dit kan bijvoorbeeld het geval zijn bij een eerste gebruik van de applicatie, wanneer de gebruiker nog een account moet creëren. De applicatie kan wel gepersonaliseerd worden op

5.1 Profielbeheer

74

basis van de toestelgegevens (bijvoorbeeld verbindingssnelheid, postcode,. . . ), het tijdstip van bekijken en het soort televisieprogramma. Zo kan een gebruiker met snelle verbinding afbeeldingen van betere kwaliteit doorgestuurd krijgen. Op basis van de postcode kan een nederlandstalige of franstalige versie van de applicatie doorgestuurd worden. De gebruikersinterface kan afhankelijk gemaakt worden van het televisieprogramma dat bekeken wordt. Zo moet deze bij de jonge gebruikers eenvoudig en geanimeerd zijn, terwijl oudere gebruikers een zakelijke user interface prefereren. 2. Anonieme personalisatie: Bij anonieme personalisatie wordt het gedrag van klanten gevolgd tijdens hun bezoek. Op dit niveau is er echter nog geen profiel ter beschikking. Uit het gedrag van de gebruiker (bijvoorbeeld de route die hij aflegt in de applicatie) zal zijn volgende stap voorspeld worden. Op basis van deze voorspellingwordt content getoond. 3. Well-known-gebruikerspersonalisatie: Bij deze vorm van personalisatie wordt gebruik gemaakt van een profiel dat door de gebruiker zelf gecreëerd werd. Hij maakt zich kenbaar door in te loggen. De applicatie kan deze login gegevens opslaan in een cookie, zodat later automatisch ingelogd kan worden. Deze vorm van personalisatie kan gecombineerd worden met real-time data zoals bij anonieme personalisatie. De login gegevens (loginnaam en paswoord) worden dan doorgegeven aan een databank, waarin het volledige profiel van de gebruiker zit. Nadat een gebruiker is ingelogd, kunnen dan bijvoorbeeld bepaalde aanbiedingen getoond worden op basis van zijn profiel. 4. Algoritmische personalisatie: Bij deze meest complexe vorm van personalisatie wordt de applicatie aangepast met behulp van speciale software. Deze software combineert verschillende soorten gegevens zoals het gebruikersprofiel, het gedrag van de bezoeker, het gedrag van andere bezoekers en de toestelgegevens. Er kan ook gebruik gemaakt worden van beslissingen die in het verleden reeds plaats hebben gevonden bij andere gebruikers met vergelijkbare kenmerken. Ook kan een profiel van een klant getoetst worden aan bepaalde vooraf vastgestelde regels (zoals de leeftijd van de gebruiker). Aan personalisatie zijn veel voordelen gekoppeld, zowel voor het bedrijf als voor de klant. Er zijn echter ook enkele nadelen voor de klant. Voordelen van personaliseren voor het bedrijf 1. Het ontdekken van nieuwe producten en diensten: Door het ontvangen van feedback kunnen nieuwe producten en diensten ontwikkeld worden, die nog beter aansluiten bij de behoeftes en wensen van de klant. 2. Verhoging van de omzet: Beter gerichte advertenties en content leiden tot meer applicatiegebruik, met als gevolg meer aankopen, reservaties,. . . Discrete real-time feedback stelt het bedrijf in staat verder in te spelen op aanbiedingen bij het gebruik van de applicatie. 3. Vasthouden van bezoekers door sticky content: Doordat de content van een gepersonaliseerde applicatie beter aansluit bij de behoeftes en interesses van de gebruiker, zal deze minder snel van een andere applicatie gebruik maken.

5.2 Beveiliging

75

Voordelen van personaliseren voor de gebruikers 1. Tijdsbesparing: Als de content goed aansluit bij de keuzes en levensstijl van de gebruiker, kan veel tijd bespaard worden. Ook kan personaliseren de input van de gebruiker reduceren. Doordat zijn gegevens opgeslagen worden, moet hij deze niet telkens ingeven wanneer hij een aankoop wenst te doen. 2. Toename van productkennis: Doordat andere gebruikers hun mening kunnen uiten over bepaalde aankopen, wordt de klant beter ge¨ınformeerd. 3. Gepersonaliseerde productinformatie: Het profiel van een gebruiker kan vergeleken worden met dat van andere gebruikers. Zo kan hem bijvoorbeeld een muzieksoort aangeboden worden, die bij andere gebruikers met vergelijkbare interesses populair is. 4. Inspelen op verwachtingen: Het gebruik van profielen laat toe om bij elk applicatiegebruik andere content te bieden. Zo kunnen bijvoorbeeld reeds gelezen artikels bij een nieuwsdienst naar de achtergrond verplaatst worden en nieuwe artikels op de intropagina weergegeven worden. 5. Veiliger: Gevoelige informatie, zoals kredietkaartgegevens, kan op deze manier vast opgeslagen worden aan de server-zijde. Deze informatie kan dan gebruikt worden bij betalingen, zonder dat deze informatie verstuurd moet worden over het netwerk. Het verzenden van de gevoelige informatie over het netwerk wordt dus beperkt tot één enkele keer, namelijk bij het aanmaken van de account. Nadelen van personaliseren voor de gebruikers 1. Geen controle over het aanbod: Doordat de bedrijven bepalen welk aanbod een gebruiker te zien krijgt, kunnen gebruikers het idee hebben onvolledig ingelicht te worden. Dit kan men oplossen door de gebruiker de mogelijkheid te bieden om al zijn gegevens te bekijken en aan te passen, ook de impliciete data die gebaseerd zijn op verwachtingen. 2. Inbreuk op de privacy: Door het gebruik van expliciete profielen en het onderzoek naar het gebruikersgedrag voelen sommigen zich bespied. Dit probleem kan gedeeltelijk opgelost worden door een duidelijk privacy-statement in de applicatie op te nemen.

5.2

Beveiliging

Een belangrijk aspect bij t-commerce is beveiliging. Dit is niet enkel een vereiste voor de gebruikers van de applicatie, maar ook voor de service providers en broadcasters. Gebruikers zijn gesteld op hun privacy. Ze willen dan ook dat hun informatie goed beschermd wordt tegen derden. Ongeautoriseerde gebruikers mogen noch aan de server-zijde, noch in de set-top box, noch over het kanaal toegang krijgen tot een gebruiker zijn gegevens. Er moeten dus authenticatiemechanismen aanwezig zijn en de data moeten geëncrypteerd worden. Ook moet ingestaan worden voor cross-application data management, zodat verschillende applicaties elkaar niet kunnen be¨ınvloeden. Daarnaast dient de data ook gecontroleerd te worden op virussen. Service providers willen dat de integriteit van hun applicaties behouden blijft en dat gebruikers hun informatie betrouwbaar kunnen ontvangen. Ook moeten ze kunnen bewijzen dat, als een

5.2 Beveiliging

76

gebruiker een dienst of product heeft aangekocht, deze dat ook daadwerkelijk gedaan heeft. Service providers moeten er tevens op toezien dat hun applicaties geen schade toebrengen aan de apparatuur (set-top box, televisiescherm,. . . ) van de gebruikers. Broadcasters willen een beveiligde communicatie tussen de gebruikers en de service provider. Daarom moet de connectie geauthentiseerd zijn en moeten alle verzonden gegevens geëncrypteerd worden. Niet-ondertekende applicaties mogen geen toegang hebben tot het return channel. Alle voorgaande beveiligingsvereisten werden gerealiseerd door het Multimedia Home Platform. Het MHP maakt hierbij gebruik van hash codes, handtekenening en certificaten. We besloten om, in het kader van deze thesis, enkel wat dieper in te gaan op authenticatie. Voor informatie over andere aspecten zoals integriteit, authenticiteit,. . . verwijzen we u naar [54].

5.2.1

Authenticatie

Authenticatie is het verifiëren van de identiteiten van alle partijen, die betrokken zijn in een transactie. De belangrijkste partijen zijn de gebruiker, de content provider en de bank. Er moet nagetrokken worden of deze partijen wel degelijk zijn wie ze beweren te zijn. Zo moet onder andere gecontroleerd worden of de gebruiker een geldige kredietkaart heeft, of zijn kredietkaartnummer bij zijn naam behoort, of de bank geldig is,. . . Bij de authenticatie van de partijen hoort ook de authenticatie van hun code. Bij t-commerce zal de client applicatie een MHP-applicatie zijn. Authenticatie komt daar tot stand door gebruik van hash codes, handtekeningen (signatures) en certificaten [54]. De hash codes zorgen voor de integriteit bij de berichtenuitwissel voor de authenticatie. Ook wordt gebruik gemaakt van ondertekende applicaties en niet-ondertekende applicaties. Niet-ondertekende applicaties hebben beperkte toegangsrechten tot bronnen en diensten. De partijen zelf moeten ook geauthentiseerd worden. Er zijn verschillende vormen van authenticatie die eventueel gecombineerd kunnen worden om een hoger of lager niveau van beveiliging op te leveren. Daarbij zijn 3 vormen van bewijs bruikbaar [55]: 1. Kennis: Dit is authenticatie op basis van bepaalde kennis van een gebruiker zoals een paswoord, een pincode of een geheime zin. Deze kennis mag echter enkel geweten zijn door de gebruiker. Daarom moet deze kennis goed gekozen zijn, zodat ze niet gekraakt kan worden. Het is verstandig om deze kennis (zoals paswoorden) regelmatig te veranderen. 2. Bezit: Hierbij wordt het bewijs van de identiteit geleverd door een fysiek herkenningsteken dat verkregen werd van een autoriserend systeem. Bij digitale televisie bestaat de mogelijkheid om identificatie op basis van bezit te realiseren, door het inlezen van smartcards. Bankkaarten en elektronische identiteitskaarten zijn een voorbeeld van dergelijke smartcards. Voor de integratie van de Belgische elektronische identiteitskaart op het Multimedia Home Platform verwijs ik graag naar de thesis van een collega-student [56]. 3. Persoonlijke eigenschap: Hierbij wordt een uniek identificerend kenmerk van een persoon opgeslagen in een authenticatiedatabase. Bij authenticatie wordt dit kenmerk van de persoon die zich wil identificeren vergeleken met de gegevens in de databank. Voorbeelden hiervan zijn vingerafdruk, stem, iris,. . . Deze mogelijkheid wordt echter nog maar weinig gebruikt en bestaat ook (nog) niet voor digitale televisie.

5.2 Beveiliging

77

Een combinatie van vorige drie methoden verbetert de authenticatie aanzienlijk. Zo kan de elektronische identiteitskaart gecombineerd worden met een login/paswoord combinatie en vindt dus een dubbele authentisering plaats. Identificatie enkel op basis van kennis (een login/paswoord combinatie bijvoorbeeld) blijkt dikwijls onveilig. Men moet bij elk gebruik van de applicatie het paswoord intypen en dit versturen naar de server. Hiertoe vergroot de kans dat anderen het paswoord kunnen onderscheppen. Er bestaan sniffers die alle gegevens, die met de remote control van de digitale televisie verstuurd worden, kunnen onderscheppen. Hierdoor kunnen alle paswoorden gemakkelijk afgeluisterd worden. Het gecombineerd gebruik van de login/paswoord combinatie en de elektronische identiteitskaart biedt hiervoor een oplossing, dit noemt men multifactor authenticatie. Enkel gebruik van een identiteitskaart geeft pickpockets vrij spel bij t-commerce applicaties, nadat ze een elektronische identiteitskaart bemachtigd hebben. We merken het verschil op tussen authenticatie en autorisatie. Autorisatie vindt plaats na de authenticatie en gaat na welke toegangsrechten de geauthentiseerde gebruiker heeft. Tot nu toe hebben we enkel de authenticatie van de gebruiker besproken. Maar hoe kan de gebruiker weten dat hij met de content provider communiceert die deze beweert te zijn? Hiervoor wordt meestal gebruik gemaakt van een gestandardiseerd authenticatieprotocol. Het meest gebruikte authenticatieprotocol is SSL (Secure Socket Layer) en kan ook gebruikt worden voor het authentiseren van de server bij t-commerce. We merken op dat TLS (Transport Layer Security) de opvolger is van SSL. Het gebruik van de JSSE API (Java Secure Sockets Extension) is een andere manier om authenticatiemechanismen te realiseren. We beschrijven kort de werkwijze van SSL. De client connecteert met de server en vertelt welke versleutelingsalgoritmes ze ondersteunt. Daarna antwoordt de server welke versleutelingsalgoritmes hij ondersteunt, zendt een certificaat naar de client en start het sluiteluitwisselingsalgoritme door gebruik te maken van de publieke sleutel cryptografie. De client vervolledigt deze sleuteluitwissel door een symmetrische sleutel te genereren die teruggezonden wordt naar de server. Dit zal de sleutel zijn die gebruikt zal worden voor de opeenvolgende datauitwisselingen. Tevens verifieert de client het certificaat door te controleren of hij te maken heeft met een vertrouwde CA (Certificate Authority). Tot slot vertelt de server welk versleutelingsalgoritme gebruikt zal worden. Bij SSL 3.0 vindt ook client authenticatie plaats, dus zal de client ook zijn certificaat opsturen naar de server die dat dan kan controleren.

5.2.2

Betalingswijzes

Nadat alle partijen geauthentiseerd zijn, kunnen (beveiligde) transacties plaatsvinden. In het geval van een t-commerce applicatie kan een gebruiker dan overgaan tot het betalen van de producten die hij wenst. Er bestaan vele verschillende vormen om een betaling uit te voeren, wat t-commerce eenvoudiger maakt. Vele methoden zijn afkomstig uit de e-commerce wereld [57]. • Smartcards: Door een smartcard kredietkaart in een smartcard lezer te steken kan de gebruiker onmiddellijk betalingen doen op een veilige manier. Deze manier wordt verwacht enorm populair te worden. • Kredietkaarten uit de Card-Not-Present-categorie (CNP-categorie): In dit geval moet geen bewijs geleverd worden dat de kaart effectief in het bezit is van de gebruiker. Na het invullen van de kaartgegevens kan een gebruiker aankopen doen. Er is één groot nadeel

5.2 Beveiliging

78

aan deze vorm van betalen: iemand, die je kaart gestolen heeft of de kredietkaartgegevens gekopieerd heeft, kan bestellingen uitvoeren op jouw naam. Een bekend voorbeeld van deze methode is VISA, waar de betalingen elke maand afgerekend worden (post-paid). Een ander voorbeeld is Mastercard. Beide voorbeelden maken gebruik van het Secure Electronic Transfer (SET) protocol voor beveiligde transacties. • Betalen via SMS: Bij deze manier moet de gebruiker een SMS sturen naar een bepaald nummer, waardoor het aankoopbedrag bij zijn mobiele-telefoonrekening wordt opgeteld. Daarop ontvangt hij een antwoord met een code die hij moet ingeven op zijn digitale televisie. Dit is ideaal voor kleine aankopen zoals bijvoorbeeld bij PayTV diensten. Deze betalingen kunnen post-paid of pre-paid gebeuren, afhankelijk van de mobiele-telefoonmaatschappij van de gebruiker. • Betalingen via telefoonrekening: Deze methode laat een klant toe een aankoop te betalen via zijn telefoonrekening. Dit wordt dikwijls gebruikt voor de verkoop van kleine producten of diensten, of voor donaties voor het goede doel. Deze methode is post-paid. Een nadeel van deze en voorgaande manier is dat de telefoonmaatschappij van de gebruiker hiervoor de toelating moet geven, wat niet altijd het geval is. • Digitale cash: Andere benamingen hiervoor zijn: elektronische cash, e-cash, ecash, digitaal geld, prepaid credits. Ze refereren naar om het even welke methode die een persoon toelaat goederen of diensten te kopen door een nummer door te sturen. De nummers worden toegekend door een bank en representeren sommen geld. Digitale cash is anoniem en herbruikbaar. In tegenstelling tot voorgaande methodes, kent de handelaar de identiteit van de shopper dus niet. • Elektronische checks: Klanten betalen door het schrijven van een elektronische check die verstuurd wordt via mail, fax of telefoon. De check is een bericht dat alle informatie bevat, die gevonden wordt op een originele check, maar is digitaal ondertekend. De digitale handtekening is gecodeerd door encryptie met de private sleutel van de klant. Wanneer de check betaald is, wordt het bericht geëncodeerd met de private sleutel van de bank wat het bewijs levert van de betaling. • Elektronische portefeuille: Bij deze betalingswijze worden details, zoals kredietkaart en adressen, opgeslagen op de server. Bij een betaling moeten dan dergelijke details niet meer ingegeven worden en kan de server de transactie beveiligd uitvoeren. • Micropayments: Analoog aan een telefoonrekening, krijgt de gebruiker ook hier een maandelijkse rekening van kleine aankopen (< 10 euro). In dit geval is geen tussenkomst van de bank noodzakelijk.

DE JAVA SMART TICKET DEMO

79

Hoofdstuk 6

De Java Smart Ticket Demo In dit hoofdstuk zullen we de theoretische onderwerpen uit de vorige hoofdstukken in de praktijk demonstreren. In plaats van een totaal nieuwe applicatie te ontwikkelen, werd gekozen voor de aanpassing van een reeds bestaande applicatie. De reden hiervan is dat het, in het kader van deze thesis, interessanter is om ons toe te spitsen op het ontwerp van de client zijde. De server zijde van een goede handelsapplicatie heeft immers een complexe architectuur, en veel tijd zou verloren gaan bij het ontwerpen van deze architectuur. Wij kozen voor een bestaande handelsapplicatie die handhelds ondersteunt, een m-commerce applicatie dus. Door de client zijde van deze applicatie uit te breiden naar digitale televisie, konden twee belangrijke onderwerpen in de praktijk onderzocht worden, namelijk het ontwerp van platform-onafhankelijke applicaties en de verschillen tussen MIDlets en Xlets. Bij de uitbreiding van een bestaande m-commerce applicatie hadden we daarbij als doel een applicatie te creëren, die tegelijk werkt voor mobiele telefoons én digitale televisie. Belangrijk was ook dat de applicatie bleef functioneren bij handheld clients na het aanpassen van de applicatie. We kozen er dan ook voor om geen aanpassingen te maken aan de server zijde, zodat alle tijd kon gespendeerd worden aan het ontwerp van de client. Door de aanpassing van een MIDlet naar een Xlet kon onder andere onderzocht worden welke verschillen deze tonen op vlak van persistente dataopslag, communicatie met de server, de interne opbouw aan de hand van componenten,. . . Tot slot konden, door de vergelijkingen tussen mobiele telefoon applicaties en digitale televisie applicaties uit hoofdstuk 2 te beschouwen, bepaalde functionaliteiten toegevoegd worden en verwijderd worden. Deze aanpassingen zullen besproken worden in sectie 6.2. Voorgaande beschouwingen verantwoorden onze keuze van de Java Smart Ticket Demo applicatie van Sun [58]. Bovendien werd deze applicatie gekozen omwille van zijn open source code en uitgebreide documentatie. In sectie 6.1 worden de functionaliteiten en architectuur van deze applicatie kort besproken en in sectie 6.2 wordt uiteengezet, welke aanpassingen gemaakt werden bij de overgang van mobiele telefoon naar digitale televisie. Hierbij wordt een opsplitsing gemaakt tussen de client zijde, de server zijde en het transport hiertussen. In voorgaande sectie worden ook bepaalde architecturale keuzes toegelicht. We willen tevens benadrukken dat het hier om een voorbeeldapplicatie gaat, waarvan alle aspecten gemakkelijk kunnen herbruikt worden bij andere t-commerce applicaties. Zo demonstreert deze applicatie het gebruik van persistente geheugenopslag om informatie te cachen, de communicatie tussen client en server via het HTTP-protocol, de integratie van de elektronische

6.1 De Java Smart Ticket Demo voor handhelds

80

identiteitskaart, de ondersteuning van meerdere talen, usability,. . . Zo zou de applicatie gemakkelijk kunnen aangepast worden naar een andere t-commerce applicatie, bijvoorbeeld een ticket dienst voor concerten, door enkel de informatie in de databanken aan de server zijde te veranderen. Maar ook andere toepassingen van t-commerce (zoals besproken in hoofdstuk 4) kunnen aan de hand van onze voorbeeldimplementatie gemakkelijker gerealiseerd worden. Hierbij denken we bijvoorbeeld aan een reisbureau dienst, PayTV diensten, loterij,. . .

6.1

De Java Smart Ticket Demo voor handhelds

De eerste Java technologie blueprint, de Java Pet Store [16], werd gepubliceerd in 2001 als een demonstratie van de J2EE technologie van Sun. Deze blueprint voorziet niet alleen voorbeeldcode voor een meerlagige e-commerce applicatie, het levert ook ontwerprichtlijnen en demonstreert veelgebruikte patronen. Sinds deze eerste publicatie zijn de Java blueprints één van de belangrijkste hulpmiddelen geworden voor ontwikkelaars, die willen bijleren over de laatste J2EE technologieën. De Java Smart Ticket Demo voegt hieraan een nieuwe dimensie toe: mobiliteit. Het demonstreert hoe complete end-to-end mobiele handelssystemen ontwikkeld kunnen worden voor het bestellen van filmtickets door gebruik te maken van J2ME MIDP voor een draadloze front end (een MIDlet applicatie dus) en een J2EE application server die toegang heeft tot een relationele database als back end. Onlangs heeft Sun richtlijnen gepubliceerd voor het ontwerp van J2EE applicaties [20]. Deze tonen hoe deze technologie efficiënt gebruikt kan worden om bedrijfsapplicaties te ontwikkelen en werden ge¨ıllustreerd in twee voorbeeld-applicaties: de Java Pet Store Demo en Java Smart Ticket Demo. De Java Pet Store Demo (zie figuur 6.1) is een e-commerce applicatie, waarbij naast een webwinkel ook een order-verwerkingscentrum, een leverancier- en een administratorgedeelte ge¨ımplementeerd werden. Na een grondige studie van deze Java Pet Store Demo kwamen we tot de conclusie, dat verschillende problemen een omzetting naar een applicatie voor digitale televisie bemoeilijkten.

Figuur 6.1: De Java Pet Store Demo Een eerste reden is de complexiteit en omvang van de applicatie. De Java Pet Store ondersteunt namelijk talrijke J2EE technologieën (zoals transaction management, beveiliging, JavaBeans,. . . ) die ook hun gevolgen hebben voor de client zijde. Een tweede reden is dat geen Java servlets voorzien zijn aan de server zijde, maar dat de


81

hele webwinkel rechtstreeks gebaseerd is op JSP. Door dit ontbreken van servlets zou de server zijde zeker aangepast moeten worden om ook digitale televisie clients te kunnen toelaten tot de applicatie. Een derde reden is de hoeveelheid content per scherm. Doordat deze opmerkelijk groot is, zou dit extra problemen veroorzaken voor de usability bij digitale televisie. Een laatste reden is dat de Java Pet Store Demo een browser client heeft. Daarom zou de keuze voor een browser client bij digitale televisie ook veel logischer zijn. Doordat DVB-HTML echter nog niet ondersteund wordt door de MHP specificatie 1.0.2 is het onmogelijk een dergelijke browser client applicatie te ontwerpen. Eventueel zou wel gekozen kunnen worden voor een DVB-HTML browser, die ge¨ımplementeerd wordt als een DVB-J applicatie (zoals bij Pontegra t-commerce en Ortikon Interactive vanuit hoofdstuk 4 het geval is). Het creëren van dergelijke browser zou echter een tijdrovende bezigheid zijn en ook nutteloos, omdat vanaf de MHP 1.0 specificatie DVB-HTML ondersteund wordt. Omwille van de voorgaande redenen leek het ons interessanter om de Smart Ticket Demo applicatie te bestuderen. De applicatie laat gebruikers toe filmtickets te kopen met een handheld zoals een mobiele telefoon of palmtop. Eerst en vooral is de applicatie stukken eenvoudiger dan de Java Pet Store. Hier zijn de client- en server zijde mooi afgescheiden door de servlettechnologie. We zagen reeds in hoofdstuk 2, bij het bestuderen van de verschillen tussen mobiele telefoon en digitale televisie, dat de hoeveelheid content, die afgebeeld moet worden op het scherm, bij mobiele telefoon ongeveer dezelfde is als bij digitale televisie. Dit vergemakkelijkt de aanpassing van de applicatie. Ten slotte maakt de Java Smart Ticket Demo gebruik van Java clients in plaats van browser clients, wat ons dus de kans geeft om een DVB-J applicatie te ontwerpen in plaats van een DVB-HTML applicatie. Onze keuze heeft natuurlijk niet enkel voordelen. We sommen enkele nadelen op. De Java Smart Ticket Demo is speciaal ontworpen voor draadloze toestellen en maakt daarom gebruik van caching mechanismen en synchronisatiealgoritmen omwille van de beperkte connectiviteit en lage bandbreedte van deze toestellen. Deze eigenschappen zijn niet altijd terug te vinden bij digitale televisie. Veel hangt af van het type verbinding dat de client heeft met de server. Als de client connecteert met een telefoonmodemverbinding, dan zullen analoge eigenschappen kunnen teruggevonden worden als bij mobiele telefoons. Maar als de client een breedbandverbinding ter beschikking heeft, dan zal alle data snel van de server gehaald kunnen worden in plaats van deze te moeten cachen en synchroniseren. Er zou dus, vóo´r het versturen van de applicatie naar de client, eerst gecontroleerd kunnen worden welk verbindingstype die heeft om daarna de geschikte applicatie door te sturen. In onze applicatie kozen we voor een combinatie van beide. In sectie 6.2 gaan we hier dieper op in. Door de beslissing om geen wijzigingen te maken aan de server zijde leggen we onszelf echter enkele beperkingen op. Hierdoor kan eerst en vooral geen extra Java servlet gecreëerd worden, specifiek voor digitale televisie (zoals te zien is in figuur 2.3). De digitale televisie client zal dus met andere woorden maximaal de functionaliteit van de mobiele telefoon client kunnen hebben. We zullen zien dat bepaalde mogelijkheden voor digitale televisie niet nodig zijn en dus weggelaten werden. Een tweede beperking is dat we de databanken en de JavaBeans componenten niet kunnen uitbreiden of aanpassen. We hebben echter toch bijkomende functionaliteiten kunnen implementeren op een andere manier. Hierop komen we ook terug in sectie 6.2. In sectie 6.1.1 van dit hoofdstuk zullen we eerst de functionaliteiten van de Java Smart Ticket Demo bespreken, waarna we vervolgens, in sectie 6.1.2, wat dieper zullen ingaan op de architectuur van de applicatie. Voor de installatie van de Java Smart Ticket Demo 1.2 en de J2ME


82

Wireless Toolkit (met daarin een MIDlet emulator) verwijzen we naar de documentatiebestanden in de doc-directory van de applicatie (/smart ticket1.2/doc). Daarin wordt ook beschreven hoe de Cloudscape database server en de J2EE Reference Implementation server, die in J2EE SDK vervat zitten, opgestart moeten worden.

6.1.1

De functionaliteiten van de Java Smart Ticket Demo

In de Java Smart Ticket Demo 1.2 kunnen klanten de volgende taken uitvoeren met hun mobiele toestellen. • Het creëren van een account, waarmee ze zich kunnen aanmelden bij de applicatie. • Het doorbladeren van gepersonaliseerde bioscooplijsten, filmlijsten en speeluren. • Het reserveren van zitplaatsen en aanschaffen van filmtickets. • Het beoordelen van geziene films met een waarderingscijfer. • Het downloaden van filmlijsten om ze offline te kunnen doorbladeren. • Het cachen van filmlijsten om het online doorbladeren van filmlijsten te versnellen. • Synchronisatie van filmwaarderingen, zodat gebruikers movie ratings kunnen ingeven vanaf verschillende toestellen of verschillende type clients (mobiele toestellen, desktops, laptops). Na het starten van de applicatie in de emulator van de J2ME Wireless Toolkit verschijnt een verwelkomingsscherm. De eerste keer dat men de applicatie in de emulator start (of op een toestel), worden de gebruikersgegevens gevraagd. Deze gegevens moeten ingevuld worden rekening houdende met de volgende regels: de login naam moet minstens vier en het paswoord minstens zes karakters lang zijn, het rekeningnummer en de eigenaar van de rekening moeten ingevuld worden, de vervalmaand moet een 2-cijferig getal zijn tussen 01 en 12, en het vervaljaar een 2-cijferig getal groter dan 03. Na het creëren van de account wordt het hoofdmenu getoond. Vanaf hier is het al mogelijk tickets te kopen, maar het is beter eerst je voorkeursinstellingen in te stellen. Dit kan door in het hoofdmenu My Preferences te selecteren. Dan kan men een postcode selecteren en aanduiden of men zich automatisch wenst aan te melden. Ook kan de synchronisatiestrategie gekozen worden. Deze bepaalt, bij conflicterende filmwaarderingen op de server en in het mobiel toestel, welke waardering gekozen wordt. Er bestaan drie keuzes: laatste waarde, eerste waarde, en expliciete vraag aan de gebruiker. In de databank aan de server zijde worden enkel filmzalen opgeslagen in de gemeentes met postcode 95054 en 95130, dus wordt best één van deze postcodes gekozen. Deze stappen worden weergegeven in figuur 6.2. Na het instellen van de accountgegevens en de voorkeursinstellingen kunnen de filmlijsten doorbladerd worden. Na het selecteren van Find Tickets in het hoofdmenu kan de postcode gekozen worden van de gemeente, waarin de bioscoop gezocht moet worden. De eerste postcode die weergegegeven wordt, is deze die ingesteld werd in de voorkeursinstellingen, er kan echter ook een andere postcode gekozen worden. Vervolgens kan een bioscoop gekozen worden uit een lijst. Een afbeelding van een holle (rode) cirkel betekent dat men online moet gaan om de filmlijst te bekijken van deze bioscoop. Een filmlijst van een bioscoop kan echter ook gedownload worden op het mobiele toestel. Deze komt dan terecht onder My saved schedules dat via het hoofdmenu


83

Figuur 6.2: Het aanmelden en instellen van gebruikersinformatie en voorkeursinstellingen bereikbaar is. In dit geval wordt een volle (groene) cirkel weergegeven. Het downloaden hiervan vraagt natuurlijk een langere connectie met de server, maar veroorzaakt wel een besparing in toekomstige connecties, omdat de filmlijsten dan offline zullen doorbladerd worden in plaats van online. Enkel bij het downloaden van een poster, het effectief reserveren van plaatsen en het betalen van tickets wordt een connectie gemaakt. Dit wordt weergegeven in figuur 6.3.

Figuur 6.3: Films online en offline doorbladeren Na het selecteren van een bioscoop kan een lijst met daar vertoonde films doorbladerd worden. Om een beter idee te krijgen van de film kan een samenvatting en een filmposter bekeken worden. Als de film geselecteerd wordt, verschijnt een lijst met de voorstellingstijdstippen. Wanneer een tijdstip gekozen wordt, verschijnt een interactief plan van de zitplaatsen voor die voorstelling. Daarop kan de gebruiker zijn gewenste plaatsen kiezen. De vrije zitplaatsen worden in het wit aangeduid, deze die reeds bezet zijn in het oranje, en de zitplaatsen die men wil reserveren in het


84

blauw. Een rode cursor duidt de huidige positie in het plan aan. Nadat minstens één zitplaats geselecteerd werd, kan een reservatie gemaakt worden. Daarop verschijnt de informatie van de reservatie en kan de bestelling uitgevoerd worden door te bevestigen. Dit wordt weergegeven in figuur 6.4.

Figuur 6.4: Zitplaatsen reserveren en tickets kopen

Figuur 6.5: Waarderingen toekennen aan films en de synchronisatie van deze waarderingen Wanneer tickets gekocht werden voor een bepaalde film, laat de applicatie je toe deze film een waardering te geven van 1 tot en met 5. Deze waardering wordt lokaal bijgehouden op het mobiel toestel en kan bekeken worden door My movie Ratings te selecteren in het hoofdmenu. In figuur 6.5 is te zien dat een waardering 3 gegeven werd aan Invasion of the Dots. De filmwaarderingen worden enkel lokaal opgeslagen tot de gebruiker kiest om deze te synchroniseren met een kopie op de server. De gesynchroniseerde waarderingen kunnen ook online bekeken worden in een web browser via de link http://localhost:8000/smartticket/portal/login.jsp. Nadat een gebruiker daar zijn gebruikersnaam en paswoord heeft ingegeven, kan hij de waarderingen opgevragen en aanpassen. Aanpassingen, die gemaakt worden met de web browser, zullen voor het mobiele toestel pas zichtbaar zijn, wanneer de gebruiker de waarderingen synchroniseert. Als een waardering aangepast wordt door de browser client én door de mobiele client, zal de gebruiker gevraagd worden welke waarde hij prefereert. Bij de gebruikersinstellingen kan de gebruiker kiezen om


85

automatisch de laatst of eerst aangepaste waarde te behouden. Dit wordt weergegeven in figuur 6.5.

6.1.2

De architectuur van de Java Smart Ticket Demo Client laag

Web laag

HTTP

EJB laag

JDBC

DB laag

SB MIDlet

servlet

EB

MIDlet

SB

Figuur 6.6: De architectuur van de Java Smart Ticket Demo Figuur 6.6 is een vereenvoudiging van figuur 2.3 en illustreert de architectuur van de applicatie. Een MIDlet voorziet de user interface op een mobiel toestel. De MIDlet communiceert met een Java servlet door middel secure HTTP. De servlet verzendt de client aanvragen naar de verschillende enterprise beans (waaronder session beans en entity beans) die instaan voor account management, filmlijsten en ticketbestellingen. Deze beans krijgen op hun beurt toegang tot een databank door gebruik te maken van de JDBC API. De applicatie is onderverdeeld in verschillende logische lagen, zodat ontwikkelaars een bepaald onderdeel kunnen veranderen zonder een ander onderdeel te be¨ınvloeden (het MVC patroon). De Client laag bestaat uit een MIDP/CLDC applicatie die de user interface voorziet. De data worden gepresenteerd in formulieren, lijsten of op canvas objecten. De persoonlijke voorkeursinstellingen, inclusief login en paswoord, en alle berichten die weergegeven worden in de applicatie (er worden namelijk meerdere talen ondersteund), worden opgeslagen in de record stores op de mobiele telefoon. De Web laag behandelt de HTTP POST aanvragen van de MIDlet. De Web laag is ook verantwoordelijk voor het sessiebeheer. Sesies worden gecontroleerd met een sessie luisteraar. De EJB laag implementeert de bedrijfslogica. De data van de klanten worden gerepresenteerd door entity beans. Aanvragen voor filminformatie en het reservatieproces worden behandeld door sessie beans. De DB (database) laag bestaat uit negen tabellen die informatie bevatten over de films en de voorstellingen. Alle wachtende reservaties worden opgeslagen in een afzonderlijke tabel totdat ze bevestigd of geannuleerd zijn. Twee tabellen worden gebruikt voor internationalisatie ondersteuning (ze bevatten de applicatieberichten in verschillende talen). De demo-applicatie bevat twee voorgedefinieerde taalinstellingen, maar andere talen kunnen eenvoudig toegevoegd worden. Model-View-Controller patroon De architectuur van de Java Smart Ticket Demo volgt het MVC patroon (zie figuur 6.7). We bekijken kort de drie onderdelen. • Model: Het model bevat de data voor de applicatie. In de Smart Ticket Demo includeert het model verzamelingen films, bioscopen, voorstellingsuren en een plan van de zitplaatsen.


86

MODEL

Synchronisation Agent

J2ME

SmartTicketFacadeBean

CONTROLLER

RemoteModel Proxy

SmartTicketServlet

UIController

ModelFacade

VIEW

LocalModel

Entity Bean

Entity Bean

Entity Bean

Entity Bean

Entity Bean

J2EE

Figuur 6.7: DHet MVC patroon toegepast op de Java Smart Ticket Demo • View: De view bevat de code voor het presenteren van data aan en het verkrijgen van data van de gebruiker. In de Java Smart Ticket Demo includeert de view bijvoorbeeld de filmlijsten en het interactieve plan van de zitplaatsen. Deze view klassen bevinden zich allen in het com.sun.j2me.blueprints.smartticket.client.midp.ui package. • Controller: De controller regelt de logische flow van de user interface. Het bepaalt ook hoe gebruikersinteracties het data model be¨ınvloeden en omgekeerd. De controller van de Java Smart Ticket Demo vraagt een gebruiker bijvoorbeeld een account te creëren wanneer hij een eerste keer de applicatie gebruikt en houdt een lokale kopie bij van de login van de gebruiker. De daaropvolgende keren dat die gebruiker inlogt, geeft de controller onmiddellijk het hoofdmenu weer, omdat hij weet dat de gebruiker al een account gecreëerd heeft. De controller wordt in de Java Smart Ticket Demo vertegenwoordigd door de com.sun.j2me.blueprints.smartticket.client.midp.ui.UIController klasse. Voor de meeste applicatieacties is de ModelFacade klasse voor de controller het toegangspunt tot de modellaag. Deze klasse bevat één methode voor elke actie in de modellaag. Afhankelijk van het type actie delegeert de fa¸cade deze naar één of meerdere van de volgende modelklassen: • De LocalModel klasse behandelt acties die toegang nodig hebben tot de lokale data op het toestel. Als bijvoorbeeld een actie bestaat uit het lezen en schrijven van voorkeursinstellingen, roept de ModelFacade klasse de juiste actie methode in LocalModel op. • De RemoteModelProxy klasse, die de RemoteModel interface implementeert, handelt acties af die toegang maken tot de J2EE server, zoals het aankopen van tickets. • De SynchronizationAgent klasse synchroniseert de opgeslagen data in de remote server met de lokale data. In de Smart Ticket applicatie worden enkel filmwaarderingen gesynchroniseerd.

6.2 De Java Smart Ticket Demo voor digitale televisie

87

De server zijde van de applicatie gebruikt een aantal Enterprise JavaBeans componenten om de business logica in te bewaren en interactie te onderhouden met een relationele databank. Wanneer de RemoteModelProxy aan de client zijde een RPC (Remote Procedure Call) oproep doet aan de server zijde, veroorzaakt de HTTP servlet SmartTicketServlet de gepaste methode in een sessie EJB, SmartTicketFacadeBean. Afhankelijk van de aard van de aanvraag zal deze verder gedelegeerd worden aan één of twee sessie beans, TicketingBean of SynchronizationBean. Voor meer informatie over de Java Smart Ticket Demo verwijzen we naar [60][59].

6.1.3

De Java Smart Ticket Demo in de realiteit

Op de emulator werkte de applicatie foutloos. De vraag is dan ook in hoeverre deze applicatie in de realiteit werkt op echte mobiele toestellen. In [61] werd naast het bestuderen van de architectuur van de Smart Ticket Demo 1.1.1, het MIDlet onderdeel van de applicatie ge¨ınstalleerd op echte Java cell phones: de Siemens SL45i, de Nokia 3410 en de Motorola Accompli 008. Enkele fouten werden ontdekt aan de server zijde en een oplossing werd beschreven. Ook werden verschillende problemen aan de client zijde ondervonden, een tekort aan geheugen was hier de hoofdoorzaak. Het artikel stelt oplossingen voor zodat de applicatie correct kan uitgevoerd worden op de Siemens SL45i en de Accompli 008. Op de Sun-website [62] wordt beweerd dat de Smart Ticket Demo 1.2 gedraaid kan worden op de toestellen gegeven in tabel 6.1. We vonden echter geen artikelen die dit verifieerden. Tabel 6.1: Mobiele apparaten waarop de Smart Ticket Demo 1.2 gedraaid kan worden J2ME aparaat Hitachi P300 Motorola i90c Nokia 3650 Nokia 7210 Sanyo SCP-8100

Verkoper Hitachi Motorola Nokia Nokia Sanyo

Draadloze drager Sprint Nextel AT&T Wireless T-Mobile Sprint

Op dezelfde webpagina worden de mogelijke servers voorgesteld voor de Smart Ticket 1.2 applicatie. Deze worden weergegeven in tabel 6.2. Wij maakten gebruik van de laatste server uit de tabel. Tabel 6.2: Servers waarop de Smart Ticket Demo 1.2 gedraaid kan worden J2EE Product BEA WebLogic Server 8.1 Oracle9iAS 9.0.4 Beta Sun ONE Studio 5, Standard Edition EAServer 4.2.2 Java 2 Platform, Enterprise Edition, Version 1.4 Beta 2 Release

6.2

Verkoper BEA Systems Oracle Sun Microsystems Sybase Sun Microsystems

De Java Smart Ticket Demo voor digitale televisie

In deze sectie zullen we het praktisch werk toelichten dat verricht werd in het kader van deze thesis: de adaptatie van de Java Smart Ticket Demo aan digitale televisie. Zoals reeds gezegd,


88

besloten we om hierbij de server intact te houden, zodat we ons volledig konden concentreren op het ontwerpen van de Xlet aan de client zijde. Door dit intact laten van de server is er zekerheid dat de applicatie ook werkt voor handhelds. We verkrijgen dus een platform-onafhankelijke applicatie die toegankelijk is voor handhelds, digitale televisie en computer. Dit intact laten van de server heeft, zoals we zullen zien, als gevolg dat we enorm beperkt zijn qua architecturale keuzes. In hoofdstuk 2 bespraken we diverse richtlijnen voor het ontwerpen van dergelijke platformonafhankelijke applicaties. Deze richtlijnen zullen we nu bediscussiëren aan de hand van de verrichte implementatie. Bepaalde architecturale keuzes zullen toegelicht worden en alternatieve methoden zullen besproken worden. We maken hierbij, net zoals in hoofdstuk 2, een onderscheid tussen de client zijde, de server zijde en de communicatie hiertussen. In dit hoofdstuk zullen ook enkele onderwerpen uit hoofdstuk 5 aan bod komen, namelijk profielbeheer en authenticatie. Doordat digitale televisie andere karakteristieken heeft dan mobiele telefoons (zie sectie 2.2) zullen bepaalde functionaliteiten ook anders zijn. Daarom geven we eerst een overzicht van de verschillen in functionaliteiten tussen de originele Java Smart Ticket Demo en de aangepaste applicatie. 1. De gebruiker kan, tijdens het gebruik van de Java Smart Ticket Demo, de televisiebeelden blijven volgen. De beelden worden centraal verkleind weergegeven en de user interface lijkt op een bioscoopzaal, waardoor de gebruiker zich ogenschijnlijk in deze zaal bevindt. 2. Terwijl bij de Java Smart Ticket Demo voor handhelds slechts één gebruiker per toestel de applicatie gebruikt, kan dit bij digitale televisie door meerdere personen. Bij de originele applicatie wordt een gebruiker, na eenmalig een account gecreëerd te hebben, telkens automatisch aangemeld bij de applicatie. Merk wel op dat de voorkeursinstelling automatisch inloggen inhoudt dat een gebruiker automatisch zijn paswoord laat invullen dat opgeslagen werd in het geheugen van de mobiele telefoon. Als een gebruiker automatisch inloggen uitschakelt, zal hem, wanneer hij een aankoop wil uitvoeren, zijn paswoord gevraagd worden. Bij de aangepaste applicatie daarentegen wordt, telkens de applicatie opgestart wordt, een welkomstscherm getoond, waarin de gebruiker kan kiezen tussen het creëren van een account of het inloggen met een bestaande login/paswoord combinatie. Naast de mogelijkheid om meerdere gebruikers te laten inloggen moet ook de mogelijkheid bestaan om op, om het even welk moment, uit te loggen. In figuur 6.8 wordt het reservatiescherm van de applicatie getoond. Uitloggen en de applicatie verlaten worden eenvoudig door het gebruik van de rode en gele kleurknop van de remote control. 3. De voorkeursinstellingen bij de originele Java Smart Ticket Demo zijn toestelgebonden in plaats van gebruikersgebonden. Men gaat er namelijk van uit dat maar één gebruiker het mobiele toestel gebruikt. Daarom werd besloten om de automatische login mogelijkheid en de keuze van de synchronisatiestrategie bij digitale televisie weg te laten. De postcode voorkeursinstelling werd echter behouden, omdat de gewenste postcode van de personen, die de digitale televisie gebruiken, meestal dezelfde zal zijn. We merken op dat het niet mogelijk was om deze gebruikersinstellingen individueel bij te houden, omdat hiervoor aanpassingen nodig waren aan de server zijde. 4. Digitale televisie biedt de applicatie de mogelijkheid om video af te spelen. Daarom werd het bekijken van filmtrailers ondersteunt door de aangepaste applicatie. Terwijl de gebruiker bij de originele applicatie enkel een poster te zien krijgt, zal de digitale televisie


89

Figuur 6.8: Het reservatiescherm van de aangepaste Java Smart Ticket Demo gebruiker daarnaast ook de trailer te zien krijgen. Het televisiebeeld dat centraal verkleind afgebeeld werd, zal dan verdwijnen en de trailer zal daar afgespeeld worden. We merken op dat we ook hiervoor geen aanpassingen deden aan de server zijde. Voor het opvragen van de trailer werd gebruik gemaakt van het unieke identificatienummer van de film. We maakten hierbij gebruik van de DVB Play-out Server V2.019, waarbij het mogelijk is in een configuratiebestand naar een MPEG transport stream te verwijzen door middel van een dynamisch linkbestand (DynamicTs.tslnk, dat een referentie bevat naar de transport stream die doorgestuurd moet worden naar de client [63]. Er werd een server gecreëerd, die dit linkbestand kan veranderen. Op deze manier kan de client applicatie, wanneer een trailer opgevraagd wordt, de server aanspreken om de verwijzing in het linkbestand aan te passen naar een verwijzing, die het identificatienummer van de film bevat. 5. Digitale televisies kunnen uitgerust zijn met een smartcard lezer. Dit biedt een extra mogelijkheid voor de aangepaste Java Smart Ticket Demo, namelijk de authenticatie op basis van de elektronische identiteitskaart. Met behulp van [56] wordt authenticatie door middel van de Belgische elektronische identiteitskaart gerealiseerd. In de applicatie wordt de gebruiker nu verplicht om, bij het inloggen of het aanpassen van zijn accountgegevens, zich te verifiëren aan de hand van zijn elektronische identiteitskaart. Dit verifiëren houdt in dat de gebruikersnaam overeen moet komen met de familienaam op de elektronische identiteitskaart en de naam van de kaarthouder dezelfde moet zijn als de voor- en familienaam op de identiteitskaart. Naast deze controle zijn er natuurlijk meerdere mogelijkheden, zoals het afbeelden van de foto van een persoon, adresgegevens automatisch weergeven,. . . Het gebruik van de elektronische identiteitskaart wordt ge¨ıllustreerd in figuur 6.9. Voor het testen van de applicatie werden twee platformen gebruikt: de ADB Q.75 Cable MHP Development Set-Top box, waarop MHP 1.0.2 en OCF for Embedded Devices ge¨ınstalleerd is, en de Osmosys set-top box emulator. Omwille van redenen die beschreven staan in [56], was het niet mogelijk om de elektronische identiteitskaart te gebruiken bij eerstgenoemde, maar enkel bij


90

Figuur 6.9: Bij het insteken van de identiteitskaart verschijnen de gebruikersnaam en de kaarthoudernaam automatisch op het scherm de Osmosys set-top box emulator. Anderzijds was het niet mogelijk om trailers af te spelen bij de emulator, maar wel bij de set-top box. Dit verplichtte ons tot het creëren van twee applicaties, namelijk TicketDemo en EIDTicketDemo. De eerste applicatie dient voor de uitvoering op de ADB Q.75 Cable MHP Development Set-Top box en voorziet de trailer-functionaliteit. De tweede applicatie dient voor de uitvoering op de Osmosys set-top box emulator en ondersteunt het gebruik van de Belgische elektronische identiteitskaart.

6.2.1

De client zijde

Zoals in 2.3.1 vermeld, moet eerst bekeken worden welk type client men wenst te creëren. Op verschillende vlakken moeten overwegingen gemaakt worden. Ten eerste is er het netwerk. Een set-top box kan op verschillende manieren in connectie staan met de server. Dit kan enerzijds een trage onderbroken connectie zijn via een telefoonmodem, maar anderzijds ook een breedband connectie. In het eerste geval zal de applicatie gelijkaardig gedrag moeten vertonen als bij de applicatie voor handhelds. De applicatie moet dus ook kunnen functioneren wanneer een modemgebruiker niet geconnecteerd is. In het tweede geval mogen gebruikers met een breedbandverbinding weinig hinder ondervinden van de aanpassingen voor de trage gebruikers. Om ook de modemgebruiker tevreden te stellen werd, net zoals bij de originele Smart Ticket Demo, de mogelijkheid aangeboden om filmlijsten te downloaden om ze daarna offline te kunnen bekijken. Gebruikers hebben ook de mogelijkheid om offline een filmwaardering in te geven om deze dan op een later ogenblik, wanneer ze geconnecteerd zijn, te synchroniseren met de server. Bovendien werd het cachen van filmlijsten ook ondersteund. De enige hinder die breedbandgebruikers hierbij ondervinden is dat ze, na het invullen van een filmwaardering, expliciet op synchroniseren moeten drukken.


91

Op vlak van beveiliging (de beveiligingsoverwegingen) werd gekozen voor HTTP, omdat zo clients achter een firewall toch nog verbinding kunnen maken met de server. We merken hier wel op dat veel beter gebruik gemaakt wordt van HTTPS, of een andere beveiligde verbinding. Door het intact laten van de server zijde kon HTTPS echter onmogelijk gerealiseerd worden, omdat hiervoor ook aanpassingen nodig zijn aan de server zijde. Extra authenticatie werd voorzien door het gebruik van de elektronische identiteitskaart. Bij het beschouwen van de platformoverwegingen was de keuze van een programmeerbare client in plaats van een browser client logisch, omdat dit soort client ook gebruikt wordt bij de originele Smart Ticket Demo applicatie voor handhelds. Het presenteren van de gebruikersinterface De presentatielogica is ge¨ımplementeerd aan de clientzijde, waardoor de user interface heel gebruiksvriendelijk gepresenteerd kon worden. Bij de transformatie van de Smart Ticket Demo kroop veel meer tijd dan verwacht in het creëren van de user interface. Zo moesten bepaalde eenvoudige MIDlet componenten bij een Xlet vervangen worden door een eigen HContainer waarin we alles zelf moesten opbouwen. Zo kan bij het creëren van MIDlets bijvoorbeeld een List gebruikt worden voor het tonen van een lijst met items, waarbij automatisch door de items wordt bewogen door het gebruik van de pijltjes. Bij een Xlet moest echter de hele lijst-structuur echter zelf opgebouwd worden en moesten luisteraars ge¨ımplementeerd worden voor het realiseren van het open neerbewegen in de lijst. Voor verdere informatie over de verschillen tussen de Xlet-componenten en de MIDlet-componenten verwijzen we naar [33][34]. Om de applicatie voor een breed publiek bereikbaar te maken, worden, net zoals bij de originele Smart Ticket Demo, meerdere talen ondersteund. Alle berichten die in de applicatie worden weergegeven (foutboodschappen, menuknoppen, titels,. . . ) worden bij de eerste uitvoering van de applicatie opgeslagen in het lokale geheugen van de client. Bij elk volgend gebruik van de applicatie wordt dan eerst in het geheugen gekeken of de berichten zich daar al bevinden. Indien dit niet het geval is, worden ze van de server gehaald. Wanneer een gebruiker de taal van de applicatie verandert, zal de applicatie heropgestart moeten worden om de nieuwe berichten (in een andere taal) af te halen om in het geheugen van het toestel te plaatsen. De navigatie werd eenvoudig gehouden en de gebruiker is in staat om vanuit elk scherm terug te keren naar het hoofdmenu, de applicatie te verlaten of uit te loggen. Wanneer op OK wordt gedrukt bij een bepaald item uit een lijst, verschijnen onderaan menuknoppen die toepasselijk zijn voor het geselecteerde item (zoals bijvoorbeeld Poster of Summary bij een geselecteerde film). Ook werd gedacht aan de usability en werd het geselecteerde item gemarkeerd. Zoals vernoemd in hoofdstuk 2 is de consistentie tussen de verschillende types client ook van belang bij platform-onafhankelijke applicaties. Daarom wordt de gehele user interface zo identiek mogelijk gehouden aan de interface van de originele client applicatie. Zo worden bijvoorbeeld dezelfde categorie-figuren gebruikt om de gebruiker het gevoel te geven dat hij met eenzelfde applicatie werkt. Figuur 6.10 toont de sterke overeenkomsten tussen de user interfaces. Het valideren van de gebruikersinputs Het valideren van gebruikersinputs aan de client zijde wordt op twee manieren gerealiseerd. Enerzijds wordt het onmogelijk gemaakt bepaalde inputs in te geven. Dit wordt bijvoorbeeld


92

Figuur 6.10: De vergelijking van de user interface bij de originele Java Smart Ticket Demo en de aangepaste versie voorzien bij de tekstvelden voor het ingeven van de vervaldatum van je kredietkaart. Het maximaal aantal cijfers dat je daar kunt ingeven is twee, waardoor het bijvoorbeeld uitgesloten wordt dat een maand met drie cijfers wordt ingegeven. Anderzijds worden, indien mogelijk, de data eerst aan bepaalde regels getoetst vooraleer ze naar de server wordt verzonden. Deze regels zijn analoog aan de regels uit sectie 6.1.1. Indien een regel overtreden wordt, verschijnt een waarschuwing op het scherm met daarin het bericht dat uitleg heeft over de overtreden regel. Zo zal een gebruiker, die geen kredietkaartnummer invult, een boodschap krijgen dat hij een kredietkaartnummer moet opgeven. Het beheer van de conversationele toestand Om de werking bij een onderbroken connectie te ondersteunen moet een Java client genoeg bruikbare data ontvangen voor hij weer offline gaat. De aangepaste Java Smart Ticket Demo maakt het een gebruiker mogelijk de filmlijst van een bioscoop te downloaden. De gebruiker kan op deze manier de filmlijst offline doorbladeren en enkel als hij zitplaatsen wil uitkiezen voor een bepaalde film wordt een connectie gemaakt. Voor deze persistente opslag wordt gebruik gemaakt van het org.dvb.io package [22]. In de aangepaste Java Smart Ticket applicatie houdt de server reservaties van een client bij gedurende een sessie. Wanneer een reservatie gemaakt wordt, worden de gereserveerde plaatsen meegestuurd in de aanvraag van de client. Wanneer de client een daaropvolgende aanvraag doorstuurt om te bevestigen of annuleren, hoeft de client de gereserveerde plaatsen niet opnieuw mee te sturen omdat de server deze informatie gecached heeft en geassocieerd heeft met de sessie ID van de client.


93

Verschillende draden voor lange operaties, het voorzien van progressie-indicatoren en het onderbreekbaar maken van operaties Bepaalde acties, vooral in het geval van een telefoonmodem-gebruiker, kunnen een langere tijd duren. Daarom worden de acties in de UIController uitgevoerd in één draad en ondertussen wordt ProgresObserverUI in een andere draad weergegeven op het scherm. Deze user interface is voorzien van een tijdsbalk en een stop knop, waardoor een gebruiker een actie kan onderbreken. Dit wordt weergegeven in figuur 6.11.

Figuur 6.11: Lange operaties worden in draden uitgevoerd, terwijl een progressie-indicator op het scherm weergegeven wordt en waarbij de actie onderbreekbaar is

De applicatie personaliseren Bij deze applicatie vindt identificatie op basis van een login plaats (zie sectie 5.1). De applicatie kan dus gepersonaliseerd worden. De enige voorkeursinstelling, de postcode, wordt aan de client zijde opgeslagen. De postcode is toestelafhankelijk. Zo zal de gebruiker afhankelijk van waar hij zich bevindt, een andere postcode ingesteld hebben. Bijvoorbeeld op een thuis televisie thuis de postcode van de gemeente waarin hij woont, op een telvisie van het bedrijf de postcode van de gemeente waarin zijn bedrijf gevestigd is,. . . De accountgegevens worden gedistribueerd opgeslagen, op de server en de client. Als een gebruiker zijn data dan aanpast, zal deze dataverandering ook doorgestuurd worden naar de server. Ook hier botsten we op een probleem door het intact laten van de server. Er worden in de servlet aan de server zijde geen methoden voorzien om de accountgegevens op te vragen. Als nu het geheugen van de set-top box plots alle data zou verwijderen, dan zouden de accountgegevens ook verloren gaan. In zo’n geval kunnen de gegevens dus niet terug opgehaald worden van de serverzijde.


6.2.2

94

De server zijde

Aan de server zijde werden dus geen aanpassingen gemaakt. Als wel aanpassingen gemaakt zouden worden aan de server, dan zou een nieuwe servlet gecreëerd kunnen worden die instaat voor de communicatie met de digitale televisie clients en die hen een aangepaste functionaliteit biedt. We willen er op wijzen dat het niet de bedoeling was een perfecte applicatie te maken, maar we wilden eerder een beeld schetsen van de mogelijkheden bij het ontwerpen van een MHP t-commerce applicatie. Natuurlijk zouden nog veel meer televisie-specifieke functionaliteiten toegevoegd kunnen worden, maar dit zou zijn tol eisen bij de aanpassing van de server.

6.2.3

Het transport tussen de client en server zijde

In een eerste poging werd geprobeerd om een HTTP-connectie tussen client en server te realiseren door middel van Sockets. Daarbij werden manueel de hoofdingen van de HTTP-paketten ingevuld. Maar na enkele problemen werd een alternatief gevonden: HttpConnection. Hiermee konden op een eenvoudige manier berichten in HTTP-pakketten verpakt en verzonden worden, zonder manueel hoofdingen te moeten aanpassen. Omwille van drie redenen werd gekozen voor het binair dataformaat. Eerst en vooral is het compact en dus de snelste manier van communiceren bij smallband gebruikers. Ten tweede zijn de verstuurde data in de applicatie weinig gestructureerd, zodat de extra kost van een XML parser zwaar zou wegen. En ten derde, als we een ander dataformaat zouden gebruiken, zou de server zijde aangepast moeten worden. We merken op dat ditzelfde dataformaat ook gebruikt wordt voor het opslaan van data in het persistent geheugen van de set-top box. Alle RPC aanvragen van de client aan de server volgen hetzelfde patroon. De eerste byte in de stroom specifieert de actiemethode die de fa¸cade sessie bean aan de server zijde moet uitvoeren. De overblijvende bytes encoderen een sequentie van UTF strings die de parameters representeren die doorgegeven moeten worden aan de remote methode. De antwoord HTTP stroom bevat de RPC terugkeerwaarde. In de Smart Ticket applicatie zijn de client en de server tightly coupled. Deze benadering kan de netwerk efficiëntie verbeteren, omdat elke RPC uitwisseling uniek ontworpen is en geoptimaliseerd. De trade-off is de ontwikkelingssnelheid en de robuustheid. Zelfs kleine veranderingen aan de serverzijde kunnen ook veranderingen noodzakelijk maken in het protocol en de parsing code aan de client zijde, en dit mogelijks op meerdere plaatsen. Ontwikkelaars moeten in het oog houden welke code be¨ nvloed kan worden, en dienen deze te updaten waar noodzakelijk.

CONCLUSIES

95

Hoofdstuk 7

Conclusies In de loop van de jaren stijgt het aantal beschikbare platformen meer en meer. Terwijl vroeger alleen diensten aangeboden werden voor desktop computers of laptops, stijgt nu de vraag naar applicaties die ook toegankelijk zijn voor andere platformen zoals handhelds, PDA’s, navigatiesystemen, digitale televisie,. . . Er is dus nood aan platform-onafhankelijke applicaties, waardoor anytime, anywhere and from any device toegang kan verkregen worden tot een dienst. Door meerdere platformen te ondersteunen kan een applicatie de voordelen benutten van elk platform zoals bijvoorbeeld het multimedia aspect van televisie, het personal companion gedrag van een mobiel toestel,. . . Tevens kan gebruik gemaakt worden van eenzelfde server voor de verschillende platformen. Zo zullen de data altijd coherent en consistent zijn bij de verschillende platformen en worden de kosten beperkt. Ook bij t-commerce applicaties speelt platform-onafhankelijkheid een belangrijke rol. Over hoe meer kanalen een bedrijf beschikt om zijn producten te verkopen, hoe meer klanten het zal lokken en hoe meer winst het zal boeken. Ook kan elk platform een andere functionaliteit aanbieden door gebruik te maken van de voordelen van dat platform. We kunnen dus concluderen dat ontwerpers van handelsapplicaties, met het oog op de technologische evolutie, zouden moeten streven naar platform-onafhankelijke applicaties. Zelfs als de applicatie voorlopig maar gebruikt dient te worden door één type client, kan de ontwerper beter deze keuzes maken, zodat hij kosten uitspaart bij een eventuele toekomstige uitbreiding naar meerdere platforms. Het ontwerp van een platform-onafhankelijke applicatie is echter geen eenvoudige zaak. Voor het ontwerp van een bepaalde client moet de ontwerper voordien enkele aspecten overwegen. Hij moet eerst en vooral de netwerkeigenschappen van de client nagaan. Hij moet zich afvragen of de client een snelle connectie heeft met het netwerk, of deze connectie onderbroken is,. . . Ten tweede moet de ontwerper zich ook afvragen in welke mate beveiliging voorzien moet worden. Clients, die bijvoorbeeld intern binnen een bedrijfsnetwerk inloggen, zullen minder beveiliging nodig hebben dan clients, die via het internet connecteren. Ook moet over de authenticatiemechanismen nagedacht worden. Ten derde moet de ontwerper ook overwegen welk platform gebruikt wordt. Zo heeft bijvoorbeeld een parkeerticket dienst voor digitale televisie niet veel nut. Hierbij moet ook de beslissing gemaakt worden of men kiest voor een Java client of een browser client. Voor een t-commerce applicatie kunnen we volgende conclusies maken. De netwerkverbinding zal afhangen van het type connectie dat de gebruiker heeft en kan variëren van smallband (via telefoonmodem) tot breedband (via kabel). Deze verbinding kan ook onderbroken geconnecteerd zijn (zoals bij telefoonmodems). Een oplossing hiervoor is dat een applicatie kan aangeboden

CONCLUSIES

96

worden in twee versies: één voor telefoonmodemgebruikers, waar synchronisatie- en cachingmechanismen worden toegepast en de data doorgestuurd worden in een binair formaat, en één voor kabelgebruikers, waar figuren bijvoorbeeld een hogere kwaliteit kunnen hebben en content verstuurd kan worden in XML-formaat. Op vlak van beveiliging zal de communicatie met de server verplicht het HTTP-protocol moeten gebruiken, omdat dit de enige manier is waarop de informatie door firewalls wordt gelaten. Voor de authenticatie van een gebruiker kan gebruik gemaakt worden van de elektronische identiteitskaart. Wat de platform overwegingen betreft zal de ontwerper, afhankelijk van de soort applicatie, een browser client of Java client moeten gebruiken. Zo zullen push georiënteerde diensten (zoals het aanbieden van een magazine) beter gebruik maken van browser clients (clients met een DVB-HTML browser), terwijl applicaties met een complexe user interface en geavanceerde interactie eerder gebruik kunnen maken van Java clients. Na deze overwegingen moet de ontwerper nagaan welke configuratie en welk profiel binnen J2ME nodig zijn voor de client waarop de applicatie zal gedraaid worden. Bij digitale televisie worden Xlets ondersteund door de Connected Device Configuration (CDC) gecombineerd met het Personal Basis Profile (PBP). Tevens moet de ontwerper rekening houden met de ontwerprichtlijnen die besproken werden in hoofdstuk 2 van deze thesis. Na het bestuderen van de voor- en nadelen van t-commerce ten opzichte van e-commerce kunnen we concluderen dat t-commerce zeker e-commerce niet zal verdringen van de markt. Bepaalde nadelen aan t-commerce, zoals de lagere resolutie of de beperktere inputmethoden, zullen gebruikers momenteel toch nog doen kiezen voor e-commerce. Naarmate de interactieve televisie evolueert, zal meer en meer gekozen worden voor t-commerce, omdat de gebruiker er vertrouwd mee wordt en omdat de nadelen zullen verdwijnen (door bijvoorbeeld beeldschermen met een betere resolutie of een extra toestenbord bijgeleverd bij de set-top box). Dit zal de toekomst uitwijzen. Voor bepaalde applicaties is t-commerce absoluut doeltreffender dan e-commerce. Vooral wat betreft reclame heeft de interactieve digitale televisie meer mogelijkheden: gebruikers kunnen interactief meer informatie opvragen tijdens reclamespotjes, tickers worden tijdens het uitzenden van een sportmanifestatie getoond met daarop de vermelding van de sponsors, reclame kan verwerkt worden in bepaalde applicaties,. . . Interessante toepassingsgebieden van t-commerce zijn bijvoorbeeld t-banking, payTV, reisdiensten, loterij,. . . Net zoals browser clients bij computer veel meer gebruikt worden dan Java clients, zullen browser clients bij digitale televisie steeds meer terrein winnen van Java clients. Het enige probleem hierbij is dat toekomstige set-top boxen niet verplicht zijn om DVB-HTML te ondersteunen. Enkele commerciële bedrijven realiseerden reeds een DVB-HTML browser voor het aanbieden van verschillende interactieve applicaties. T-commerce biedt ook enkele nieuwigheden op vlak van profielbeheer. Doordat de set-top boxen een unieke code hebben, kan deze code gebruikt worden door de server voor het bijhouden van een profiel van het hele gezin dat het toestel gebruikt. Ook wordt het in de toekomst mogelijk bepaalde gegevens uit de set-top box te verkrijgen zoals de postcode. Voorgaande informatie zou dan kunnen gebruikt worden om applicaties te personaliseren. Om het vertrouwen van een gebruiker in digitale televisie te bewaren, moeten zeker extra maatregelen getroffen worden. Zo kan eventueel een smart card lezer gebruikt worden voor het inlezen van de elektronische identiteitskaart. Door dit soort authenticatie te combineren met een login/paswoord, wordt een dubbele beveiliging voorzien. Hierbij is het vanzelfsprekend dat

CONCLUSIES

97

beveiligde connecties gebruikt worden en dat de data geëncrypteerd worden. Dit alles werd in de praktijk getest door de Java Smart Ticket Demo voor handhelds aan te passen aan digitale televisie. Hierbij kan geconcludeerd worden dat de overgang van MIDlets naar Xlets niet zo eenvoudig is verlopen als verwacht. Zo moest de user interface en de user interactie bij Xlets volledig manueel opgebouwd worden, terwijl MIDlets standaard componenten (zoals bijvoorbeeld List) bevatten, waarbij de user interface en de user interacties automatisch gegenereerd worden. We maakten de beslissing om, omwille van de eenvoud, geen aanpassingen te maken in de code van de applicatieserver. Op deze manier ondersteunen reeds ge¨ınstalleerde applicatieservers rechtstreeks ook digitale televisie. Een nadeel hiervan is dat de applicatie voor digitale televisie maar maximaal dezelfde functionaliteiten kan benutten als de applicatie voor handhelds, doordat dezelfde servlet werd gebruikt. Omwille van deze beperktheid kunnen we concluderen dat het noodzakelijk is om per platform een servlet te voorzien aan de server zijde. Daardoor kunnen alle sterktes optimaal benut worden per platform door het aanbieden van bepaalde functionaliteiten via een eigen servlet. Ondanks deze beperking slaagden we er toch in om extra functionaliteiten te voorzien zoals het ophalen van filmtrailers en de authenticatie op basis van de elektronische identiteitskaart. Deze aangepaste Java Smart Ticket Demo ondersteunt enkele basismechanismen van alle tcommerce applicaties. Deze mechanismen zouden dus gemakkelijk herbruikt kunnen worden voor het creëren van een applicatie uit een ander toepassingsgebied. Het ge¨ımplementeerde werk kan dus een basis zijn voor toekomstig werk omtrent t-commerce. Daarnaast kan de applicatie ook als voorbeeld gezien worden van een platform-onafhankelijke applicatie, die ge¨ımplementeerd werd volgens alle omschreven richtlijnen.

INHOUD VAN DE BEGELEIDENDE CD-ROM

98

Bijlage A

Inhoud van de begeleidende Cd-rom Volgende mappen zijn beschikbaar op de cd-rom: • EIDTicketDemo: bevat de broncode en documentatie van de aangepaste Java Smart Ticket Demo waarbij de Belgische elektronische identiteitskaart ondersteund wordt. • Software: bevat zowel de programma’s als de bibliotheken die nodig zijn voor het uitvoeren van de Java Smart Ticket Demo. Voor de installatie van de Java Smart Ticket Demo 1.2 verwijzen we u naar de Software/smart ticket1.2/docs/user directory. • Thesisbundel: bevat de volledige thesisbundel in pdf formaat. • TicketDemo: bevat de broncode en documentatie van de aangepaste Java Smart Ticket Demo waarbij de gebruiker filmtrailers kan opvragen. De server die meehelpt aan het leveren van de trailers kan opgestart worden met het commando: java TicketDemo/bin/server.ServerMain

BIBLIOGRAFIE

99

Bibliografie [1] Mobile Enterprise (Handy Parking) Project, Aug 2002. http://www.cs.fh-aargau.ch/˜ gruntz/projects/parking [2] Design Issues for Dual Device Learning: interactive television and mobile phone. Lyn Pemberton and Sanaz Fallahkhair. School of Computing, Mathematics and Information Sciences, University of Brighton, UK. [3] Cross-platform SMIL player. Kari Pihkala, Pablo Cesar, Petri Vuorimaa. Telecommunications Software and Multimedia Laboratory. Helsinki University of Technology, Finland. [4] http://www.amiga.com [5] http://www.pixelplay.com/ [6] http://www.httv.fr/ [7] http://www.wikipedia.org [8] Emerging Technologies Language in Action: From Webquest to virtual Realities. GodwinJones, 2003, Language Learning and Technology [9] Learning can happen anywhere: a mobile system for language learning. Kadyte. 2003 [10] The mobile interactive learning environment (MOBILE) and a case study for assisting elementary school English learning. Tan, T. & Liu, T. (2004). The 4th IEEE International Conference on Avanced Learning Technologies ICALT 2004. p.530-534 [11] Using Mobile Applications for Use of Greek during the Olympic Games 2004. Pincas, A. 2004. Proceeding of M-learn conference 2004. [12] MIDP Style Guide. Copyright 2002, Sun Microsystems, Inc. http://java.sun.com/j2me/docs/alt-html/midp-style-guide/style-guideTOC.html [13] Interactive Television Style Guide. http://www.bbc.co.uk/commissioning/newmedia/pdf/styleguide2 1.pdf [14] Branding and Usability. Spool, J. 1996. [15] http://www.projectliberty.org/ [16] http://java.sun.com/developer/releases/petstore/ [17] http://www.x-smiles.org

BIBLIOGRAFIE

100

[18] The Interactive TV Web. DVB-HTML. http://interactiveweb.org/tutorial/mhp/dvb-html.shtml [19] Designing Wireless Clients for Enterprise Applications with Java Technology. Copyright 2003, Sun Microsystems, Inc. [20] Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition. I. Singh, B. Stearns, M. Johnson, Enterprise Team. Copyright 2002. [21] http://en.wikipedia.org/wiki/Java Web Start [22] The Interactive TV Web. File Systems. http://interactiveweb.org/tutorial/mhp/filesystems.shtml [23] J2EE technology Web site. http://java.sun.com/j2ee/ [24] J2EE Tutorial. S. Bodoff, D. Green, K. Haase, E. Jendrock, M. Pawlan, B. Stearns. Copyright 2001, Addison-Wesley. http://java.sun.com/j2ee/tutorial/ [25] Professional JSP (2nd edition), Brown et al, 2001 [26] Java Technology and XML. T. Violleau. Sun Microsystems. 2001 [27] Using XML in the standardization of digital TV with MHP (Multimedia Home Platform). J.C. L´ opez, A. Gil, J.J. Pazos, C. L´ opez, M. Ramos, R.F. Rodr´ıguez. University of Vigo, Spain. [28] PersonalJava. http://java.sun.com/products/personaljava/ [29] http://java.sun.com/products/cldc [30] Understanding J2ME Application Models. Eric Giguere. 2002. [31] The Java Tutorial, Third Edition: A short Course on the Basics. M. Campione, K. Walrath, A. Huml. [32] http://java.sun.com/docs/books/jls/second edition/html/execution.doc.html [33] J2ME Tutorial, Part 2: User Interfaces with MIDP 2.0. Vikram Goyal. http://today.java.net/pub/a/today/2005/05/03/midletUI.html [34] The MHP Tutorial. Steven Morris. http://www.interactivetvweb.org/tutorial/mhp/xletintro.shtml [35] http://www.ebay.be [36] http://www.nionex.de [37] http://www.empolis.de [38] The Browser Solution for MHP by NIONEX. Demonstration Documentation. [39] Pontegra t-commerce. http://www.nionex.de/home/loesungen/itv/pontegra t commerce.jsp [40] Ortikon Interactive. http://www.ortikon.com

BIBLIOGRAFIE

101

[41] http://www.amazon.com [42] http://www.navic.tv/solutions/solutions for advertisers/tcommerce.php [43] http://www.digisoft.tv/eu/products/digi/digibank.html [44] http://www.digisoft.tv/eu/products/digi/digitravel.html [45] http://www.digisoft.tv/eu/products/digi/digipromo.html [46] http://www.digisoft.tv/eu/products/digi/digigamble.html [47] http://www.digisoft.tv/eu/products/digi/digilottery.html [48] http://www.digisoft.tv/eu/products/digi/digipaytv.html [49] http://www.espial.com/index.php?action=products,iptv applications [50] http://www.biap.com/products/tcommerce.php [51] Marketers lose confidence in TV advertising. Abbey Klaassen. http://adage.com/mediaworks/article?article id=107965 [52] Het belang van klantinformatie voor e-commerce. Jan Pieter Kroon. 1999 [53] Personalisation of Web Search. Kevin Keenoy and Mark Levene. School of Computer Science and Information Systems, Birkbeck, University of London [54] Home network application security (MHP). Junchun Luo. Department of Computer Science and Engineering. Helsinki University of Technology. Finland [55] http://nl.wikipedia.org/wiki/Authenticatie [56] Integratie van de Belgische elektronische identiteitskaart op het MHP-Platform. Joost Cammaert. 2006 [57] Beginner’s Guide to Ecommerce. June Campbell. Nightcats Multimedia Productions revised 2003. [58] Java BluePrints for Wireless. http://java.sun.com/blueprints/wireless/ [59] http://developers.sun.com/techtopics/mobility/midp/articles/smartticket1 2/ [60] End-to-End J2ME Application Development by Example - Introducing Smart Ticket. Norman Richards en Michael Yuan. 2003. [61] Java Smart Ticket Demo Application Scrutinized. Dominik Gruntz en Ren Mller. University of Applied Sciences. Aargau, Switzerland. [62] 2003 Java Deployathon. http://java.sun.com/developer/technicalArticles/J2EE/deployathon4/ [63] Analyse en ontwerp van een framework voor educatieve televisie op het MHP-platform, 7.1.2. DVB play-out server. Toon De Pessemier. 2006

Analyse en ontwerp van een t-commerce MHP applicatie voor interactieve digitale televisie

Recommend Documents